My Monkey Do

A Log of Coding Solutions

SVG height not scaling properly on IE 10

by

Problem

IE 10 shows a skewed svg image who’s width is set to a specific value and height is auto.

 

Solution

The problem is the width and height in the SVG file is set and IE is following those specs if you don’t set it.  So if you’re image is 100×100 and you set only the width to 50px, the height will remain at 100px.  The solution is to remove the width and height attributes in the <svg> tag.

Caveats

A solution on a github gist suggests that removing the width and height attributes force the image to occupy the full width of its container in non-IE browers.  All my current images with SVG are supposed to fill the width so this isn’t a problem for me.
Link to the gist: https://gist.github.com/larrybotha/7881691

wpdb insert returning false

by

Problem

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

 

Solution

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.

WP Cron with Basic Authentication

by

Problem

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

 

Solution

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.

Where is wp_capabilities?

by

Problem

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.

 

Solution

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' )

Chrome Zoom Shifts Layout

by

Problem:

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

Solution:

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.
});
});

WordPress REST API schema property format: email

by

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.