Web Development Wordpress

WordPress 4.4 Sidebar Naming

With WordPress 4.4 rolling out a few issues have come up around sidebars and widgets but one fix is not immediately obvious. When adding a sidebar, the naming previously was not case sensitive but it is now. The example below would not work:

 'name'=>'Homepage Widget',
 'description' => 'Main Area on the Homepage',
 'id' => 'homepage',
 'before_widget' => '',
 'after_widget' => '',
<?php if (!dynamic_sidebar('HomePage')) : ?>
<?php endif; ?>

Now, make sure that the sidebar call uses the exact ID.

<?php if (!dynamic_sidebar('homepage')) : ?>
<?php endif; ?>

Fix Facebook Fix Plugin and Facebook Meta Data

There is an awesome plugin out there which fixes errors that can crop up with incomplete Facebook Meta Data. Basically when Facebook goes to submit a Like they attach a lot of information to it such as a description, link, type, so on. This data is what ends up in Facebook Insights (among other places I am sure) and is generally used to categorize the information. What Fix Facebook Like does is rebuild that data, which can be outputted wrong from WordPress.

There is a small issue with the plugin though, it comes down to the Type field used by Facebook, “og:type.” If this “og:type” is wrong Facebook considers it a showstopper and the Like system breaks. The plugin fills this out automatically and every now and then hits an “og:type” Facebook doesn’t recognize and everything grinds to a halt. The easiest fix is to go into the PHP for the Fix Facebook Like and remove the line:
< meta property="og:type" content="" />

Removing the line means Facebook will try and figure out the type on it’s own. Alternatively you can look up the “og:type” and fill it out manually, there is a site here that will do just that for you. The modified plugin means all your Likes will go through and have the proper meta information with them!


Hide Google Analytics when Logged into WordPress

Another quick but helpful tip. Most sites use Google Analytics to track visits, pageviews and overall traffic but if you are constantly updating a site you can end up wildly skewing your analytics with constant refreshes. To avoid this, you can go into Google Analytics and add an IP Filter:

However this doesn’t help much if your updating from different coffee shops, or cities for that matter, on a regular basis. For an easy fix use WordPress “if user logged in” function.

if ( is_user_logged_in() ) {
//Also a good place to add scripts specific to logged in users.
} else {
//script code
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-xxxxxxx-x']);

(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
//script code

Now, no matter where, if you are logged in your constant reloads won’t affect your analytics.


Quick fix for rel=”category tag” in WordPress

Here is a quick tip for helping WordPress, WordPress 3.2 specifically, with the HTML5 spec. HTML5 spec says that only certain rel types are allowed and WordPress’ “category tag” isn’t one of them. Fortunately I found a good bit of code here which strips out the current rel=”category tag” and adds a rel=”nofollow” as a filter in the fuctions.php file for the theme. By adding it to the functions.php for the theme this provides a theme wide fix rather than having to edit individual templates.

I altered the code a bit for my uses, however, as I’d still like the search engines crawling around my site so I stripped the code down to:
add_filter( 'the_category', 'add_nofollow_cat' );  function add_nofollow_cat( $text ) { $text = str_replace('rel="category tag"', "", $text); return $text; }
Now the W3 Validator has one less WordPress quirk to pickup on.

%d bloggers like this: