wpdb insert returning false


When running wpdb->insert the result returns false.  All the values seem to check out to be fine.



The problem might be due to this bug in WordPress.  Basically one of your fields is too long and WordPress is not completing the insert.  Reading through the ticket, it seems it is a WordPress error and not a MySql error so it would be pretty difficult to go through all the fields, determine the column field size limits, and then return an error of some sort.  Anyway, this is one possible reason to wpdb->insert returning false.

Tagged with: ,

WP Cron with Basic Authentication


WordPress’ cron doesn’t work when a site has basic authentication.  You basically would get a 401 error.



Thanks to Nick Ohrn (in 2014) this problem is solved with a simple mu-plugin.  You just need to set the username and password in a constant in wp-config and add some code to the mu-plugins directory.  Here is his quick tip.

Tagged with:

Where is wp_capabilities?


After creating a user with a certain role I need to do a custom sql query where it only selected users of a specific role.  This failed to find anything:

select u.ID, u.display_name, u.user_login
from $wpdb->users as u
inner join $wpdb->usermeta as umr
on ( umr.user_id = u.ID )
and ( umr.meta_key = 'wp_capabilities' )

$user = get_userinfo( $user_id );
var_dump( $user->roles );

get_userinfo got the right role, so saving was correct.

$caps = get_user_meta( $user_id, 'wp_capabilities' );
var_dump( $caps );

$caps was null.  weird.



You learn something new everyday.  After looking through the WordPress core code I found that the meta key is actually composed of the table prefix and ‘capabilities’.  So the correct query would be:

select u.ID, u.display_name, u.user_login
from $wpdb->users as u
inner join $wpdb->usermeta as umr
on ( umr.user_id = u.ID )
and ( umr.meta_key = '" . $wpdb->prefix . "capabilities' )

Tagged with: , ,

Chrome Zoom Shifts Layout


When zooming in or out on Chrome, the widths of elements increases very slightly and causes some elements to shift to the next line.


The actual problem is Chrome adjusts the widths of elements by tenths.  So something like 141px will turn into 141.1px which in turn causes all your elements to be just slightly bigger and not fit on one line.

I thought the solution to this was to go through all the problem elements and re-set the size to the original size.  However, it turns out you just have to go through the elements in javascript and Chrome will re-set the widths for you.  This leads me to believe this width adjustment on zoom is a bug in Chrome.  Below is what solved my problem in jQuery:

var menuItems = $("#navigation .menu a");
$(window).resize(function() {
menuItems.each(function(i, v){
//by just going through the menu items it seems to fix the width rounding on zoom.

Tagged with: ,

WordPress REST API schema property format: email

Problem:  When setting a property type to ’email’ like so:

$schema = array(
'$schema' => 'http://json-schema.org/schema#',
'title' => 'user',
'type' => 'object',
'properties' => array(
'email' => array(
'description' => __( 'The optional email address for the something.' ),
'type' => 'string',
'format' => 'email',
'context' => array( 'edit' ),
'required' => false,
) )


WordPress checks if it’s an email like it should, but it does this even if an empty string is passed.  If this needs to be an optional field, the only way I see around it is to not set the format to email.

Tagged with: ,

WordPress Capabilities with map_meta_cap and user_has_cap

The two functions, map_meta_cap and user_has_cap allow you to change capabilities on the fly without having to add to roles in the database.  These also allow you to have a ton of flexibility.

Some examples from the talk:

 If you can edit pages, you can edit widgets:
add_filter( 'user_has_cap',
function( $caps ) {
if ( ! empty( $caps['edit_pages'] ) )
$caps['edit_theme_options'] = true;
return $caps;
} );

Give secondary “administrators” less control:
add_filter( 'user_has_cap',
function( $caps, $cap, $args ) {
$user_id = $args[1];
$user = new WP_User( $user_id );
$email = $user->user_email;
if ( $email != get_option( 'admin_email' ) )
$caps['manage_options'] = false;
return $caps;
}, 10, 3 );

Don’t let anyone delete users:
add_filter( 'map_meta_cap',
function( $required_caps, $cap ) {
if ( 'delete_user' == $cap || 'delete_users' == $cap )
$required_caps[] = 'do_not_allow';
return $required_caps;
}, 10, 2 );

Only administrators can delete published posts:
add_filter( 'map_meta_cap',
function( $required_caps, $cap ) {
if ( 'delete_post' == $cap )
$required_caps[] = 'manage_options';
return $required_caps;
}, 10, 2 );

Require editors to approve posts:
add_filter( 'map_meta_cap',
function( $required_caps, $cap ) {
if ( 'publish_post' == $cap || 'publish_posts' == $cap )
$required_caps[] = 'edit_others_post';
return $required_caps;
}, 10, 2 );

WordPress 4.6 crashed my site

Fatal error: Cannot redeclare the_post_thumbnail_caption() (previously declared in ….

This error occurs because the_post_thumbnail_caption is a new function in WordPress 4.6.  However, people have been using this function for over 5 years now.  How?  Stackoverflow and other WordPress forums are flooded with questions asking how they can print out the thumbnail caption.  Since this wasn’t a built-in function before, the answer was to make your own function which was appropriately named the_post_thumbnail_caption.

Many theme authors, myself included, are now guilty of simply copy-pasting this function without adding their own theme prefix.  To avoid errors like this, functions within a theme should be prefixed with something unique to the theme like “mymonkeytheme_the_post_thumbnail_caption”.

If you have this error, contact your theme author and ask them to fix the theme.


Tagged with: ,

Git Copy

This may be obvious to the git experts, but I am not that.  There also may be a better way to do this, but again, not a git expert.

I have a git repo set up on WPEngine, but they only allow the whole server to be a repo, not just a single plugin.  This was a problem since the whole server directory was not in my current repo.  So it was either make a new repo which was basically a copy of my current repo but a different folder structure or keep on using SFTP.  I decided to make a new duplicate repo.  The problem (which i also had with SFTP) was finding the files that changed and pushing them to the server.  This is both error-prone and slow.  I found a script that could copy all changed files from the last commit into my WPEngine deploy directory and also discovered a way to do this automatically when pushing from my main repo.

Create/Save this script in .git/hooks/pre-push file.  This would be in the main git repo I work in.  This copies all changed files to the WPEngine deployment repo.


MOST_RECENT=$(git log -n 1 –pretty=format:’%h’)
PREV=$(git log –skip=1 -n 1 –pretty=format:’%h’)

echo “Coping to $TARGET”
for i in $(git diff –name-only $MOST_RECENT $PREV)
# First create the target directory, if it doesn’t exist.
mkdir -p “$TARGET/$(dirname $i)”
# Then copy over the file.
cp “$i” “$TARGET/$i”
exit 0

Thanks to the following articles about pre-push hooks and how to get the files between commits.



WordPress the_title filter changed in nav menus

I haven’t had time to look into the exact reason or the exact version this changed, but as of at least WordPress version 4.5.2 the nav menu uses the_title multiple times for one item.

For example if your theme used something like this:

function menu_title_filter( $title ) {
return $title . ' | ';
add_filter( 'the_title', 'menu_title_filter' );

It would have one ” | ” after each menu title in previous versions, but in WordPress 4.5 ish it would show two ” | “.  Again, haven’t looked at the exact cause that changes this, but the solution is to check if the item you’re looking at is a nav_menu_item:

function menu_title_filter( $title, $id ) {
$item = get_post( $id );
if ( $item->post_type != 'nav_menu_item') return $title;
return $title . ' | ';
add_filter( 'the_title', 'menu_title_filter', 10, 2 );

Tagged with:

Relative positioning of table rows and row groups is now supported. This site may need to be updated because it may depend on this feature having no effect.

Firefox displayed this warning in the Firebug console.  This warning indicates an absolutely positioned does not consider a table element relatively positioned so it may not appear as expected.  A better explanation is here:


and solution to fix is here:


Tagged with: , ,