Category Archives: WordPress

Can you turn advanced custom fields into a standalone plugin?

The short answer is no, not completely standalone.

You can make a plugin from the output of the Advanced Custom Fields’ export to PHP option, but it still requires that the site have the full Advanced Custom Fields plugin installed.

There is a way to hide the ACF plugin’s user interface by defining define( ‘ACF_LITE’, true ); before including the acf.php file.

For simple custom fields, you might be better off defining them through native WordPress code

Git plugins within WordPress on WP Engine

I am currently 0 for 2 in finding plugins for managing Git that play nicely with WP Engine.

The plugins I tried were:

  • Revisr
  • VersionPress


A way to commit and push changes from within the WordPress dashboard to a git based repository


WP Engine’s approach for using git works well most of the time.  I don’t track the WP core in my repositories, but I do track plugins.  I do this to track custom developed plugins and bug fixes/enhancements to freely available plugins that never get pushed into their original code base.

The benefit of using managed hosting is that they automatically update plugins if necessary for security fixes.  The bad part is that these updates are only made on the production server and don’t end up in the repository.  Also, from time to time, they will ask you to remove a plugin from their disallowed plugins list.  If it isn’t removed within a week, they will remove the plugin and this change doesn’t end up in the repository either.  Additionally, managing plugin updates through the admin panel requires deleting the local copy, downloading the changes via SFTP, committing, and pushing to the remote.  The desired goal is to cut out these additional steps and commit directly from within the WordPress back-end.

Lastly, I also like knowing when plugins were first installed and especially if someone else requested the functionality.





“I made Revisr to simplify the development process,” Matt Shaw the developer told WP Tavern. “There are currently no plugins on that allow developers or site admins to use all of the main features of Git through the WordPress dashboard, and I made Revisr to do just that,” he said.

I installed this plugin first, but wasn’t able to get it running without the installation path to git:


WP Engine doesn’t expose git for security reasons.  0 for 1 so far.




I installed VersionPress and got a notice that it required a newer PHP version on the server.

I admittedly installed this without checking the disallowed plugins list.  I got an email the next day informing that VersionPress is disallowed on WP Engine.

VersionPress — In order to function properly, this plugin needs access to server level functions that we disallow for security purposes. – WP Engine Disallowed Plugins

I am 0 for 2.

A final note

One interesting thing I read, but cannot seem to find again, is that one of these plugins has dropping the installed git requirement on its road map.  If I can find that again or becomes a reality, I’ll update here.

Use the Advanced Custom Fields plugin for stashing code

Anyone working with code in the WordPress TinyMCE WYSIWYG editor will have had their code blown away when switching between “Text” (HTML) and Visual editing modes.

One of the many uses of Advanced Custom Fields plugin is to create a text area to stash code associated with a page or post that the editor can’t touch.


It’s a similar idea to using the plugin to add custom JavaScript or CSS to a page/post, except the field isn’t exposed in the theme.

This serves to only store the code alongside the post/page in the database.

This will not prevent the editor from modifying the code again in the future if it is pasted back into the editor, but it is a convenient place to copy the code from again.

If you want a more permanent solution you could disable the visual editor, remove the filtering, or other options.


Pure CSS Tooltips

Code and example of a pure CSS


You found it!

And we can put HTML inside!

working in WordPress





TIL: WordPress where to use is_category() over is_tax() function

Today I learned that the WordPress function is_tax() returns false on arc hive pages.

According to the WordPress codex, “You should use is_category() and is_tag() respectively when checking for category and tag archives.”

My situation:

It appears that a 3rd party developer was implementing some specific code in a post using the is taxonomy function is_tax(“category”, “category-name”) and when trying to do the same on a category archive page just copied and pasted the code and called it a day.

The code didn’t work for the archive page and was left alone for some time.  I realized it wasn’t working on the category page and upon investigation learned that the is_tax() function would always return false for a category archive page.

WordPress’ .htaccess rules Decoded

If your WordPress’ .htaccess file has not been modified it should look like this:

# BEGIN WordPress / # END WordPress Tags

WordPress may modify anything within these two tags and anything you add should be outside of these tags.  Source: WordPress Codex

<IfModule mod_rewrite.c> / </IfModule> Tags

If your server doesn’t have the rewrite module or it isn’t properly enabled, the rewrite rules with the If tags will not be executed. Sources: WordPress Codex Using_Permalinks, Glossary

RewriteEngine On

The RewriteEngine directive enables or disables the runtime rewriting engine. Source: Apache documentation

RewriteBase /

The RewriteBase directive allows you to define a root directory for your website.  Source: RationalSpace RewriteBase Explained

RewriteRule ^index\.php$ – [L]

Prevents requests for index.php from being rewritten, to avoid infinite loops. If the request is for index.php the directive does nothing – and stops processing rules [L]. Source: StackOverflow

[L] flag

The [L] flag causes mod_rewrite to stop processing the rule set. In most contexts, this means that if the rule matches, no further rules will be processed. Source: Apache documentation

-f and -d flags

These Rewrite Condition flags allow you to perform various file attribute tests

Is regular file.
Treats the TestString as a pathname and tests whether or not it exists, and is a regular file.

Is directory.
Treats the TestString as a pathname and tests whether or not it exists, and is a directory.

Source: Apache documentation

The remaining code:

Are rules that are processed in order.  First it checks for a filename, then it checks for a directory, and if both of those fail the request is redirected to index.php. Source: SitePoint

Review of “5 Simple .htaccess Tips to Tighten Your Site’s Security”

The article published on June 26, 2014 provides 5 Tips for upping a WordPress site’s security.  Original article:

The tips are:

  1. Protecting wp-config.php
  2. Prevent Directory Browsing
  3. Prevent Image Hot Linking
  4. Restrict Access to Your Admin Area
  5. Protect Your .htaccess File

Of these recommendations, you can test quickly whether you are already protected against some of these.  You should get a blank page or a 403 Forbidden page.  Quick test:

  3. See the section below (coming soon)
  4. See the section below (coming soon)

1.  Protecting wp-config.php

The Protecting wp-config.php advice comes directly from

Test it:

wp-config.php No Closing Tag

Working on my Raspberry Pi LAMP and WordPress install, I just so happened to notice that the wp-config.php file didn’t include the closing php tag ?>  and was curious why.

A user Mark / t31os on the WordPress support forum suggested:

When you are distributing files and can expect users to be using dodgy editors that add extra lines or erroneous spaces on the end of files….. and such…..

It’s quite easy for extra spaces to end up on the end of a file, and if you’re using several includes tracking these spaces down can be a pain, especially if you’re dealing with lots of files… spaces after closing PHP tags is known to cause various issues including invalid headers…

Of course there are cases when not using closing tags causes problems to, so it’s catch 22…

From the PHP documentation:

The closing tag of a PHP block at the end of a file is optional, and in some cases omitting it is helpful when using include or require, so unwanted whitespace will not occur at the end of files, and you will still be able to add headers to the response later. It is also handy if you use output buffering, and would not like to see added unwanted whitespace at the end of the parts generated by the included files.


Gravity Forms Notifications/Confirmations Shortcodes

If this actually exists elsewhere, I haven’t been able to find it.

Helpful shortcodes (Merge Tags as Gravity Forms calls them) for confirmations and notifications in the Gravity Forms WordPress plugin.

Your site admin email {admin-email]
The form’s name {form_title}
All fields {all_fields}
Advanced Fields (where # is the Field ID)
Name – Prefix {Name (Prefix):#.2}
Name – First {Name (First):#.3}
Name – Middle {Name (Middle):#.4}
Name – Last {Name (Last):#.6}
Name – Suffix {Name (Suffix):#.8}
Time {Time:#}
Address (Street Address) {Address (Street Address):#.1}
Address (Address Line 2) {Address (Address Line 2):#.2}
Address (City) {Address (City):#.3}
Address (State / Province) {Address (State / Province):#.4}
Address (ZIP / Postal Code) {Address (ZIP / Postal Code):#.5}
Address (Country) {Address (Country):#.6}


User IP Address {ip}
Date (mm/dd/yyyy) {date_mdy}
Date (dd/mm/yyyy) {date_dmy}
Embed Post/Page Id {embed_post:ID}
Embed Post/Page Title {embed_post:post_title}
Embed URL {embed_url}
Entry Id {entry_id}
Entry URL {entry_url}
Form Id  {form_id}
Form Title  {form_title}
HTTP User Agent  {user_agent}
HTTP Referer URL  {referer}
User Display Name  {user:display_name}
User Email  {user:user_email}
User Login  {user:user_login}



  • Page was not included
  • Section (break) was not included Hashes | 3.39 MB

SHA256: d8a800cfbd24575f209cdd11fb310b21c4f996f2ff5a85592ce3cba376075967

SHA384: f09c35fa9ef9da090c70546d290fbde97b68d1fea988bee8036531cb53c8ccbd10694258112e67d3582ebfbe7b119579

SHA512: 682e0e470024df7b7097c4f8c160f21bc2e275923db0dec8b44f26aa1234d911069aadc70ccec0e6e564859b6e28884b1d524fe2a5c787f41e5a46ce4f8d8ec5

Deprecated hashes

MD5: 44d18a0583edad608aa57cb2a5f52c30

SHA1: 08c60355ddbb33c93356e50a4e2de97ea66d7f1d