I recently updated my blog from the Blogger to a new WordPress web site. One of the main reasons was that I found my Blogger site was not responsive and was definitely not mobile friendly. I enjoyed using the simple interface for posting items (though rarely) but felt that I could do a whole lot more with WordPress.
It took me a while to find a good template that I liked but I did manage to find the one that offered a nice flow and presentation of the blog content. With the hundreds of plug-ins available I was able to tweak the site to include many things that were not options with Blogger.
I did however end up having to tweak a few things. The template that I was using described my posts as ‘hentry’. This has to do with the meta (or hidden) details that make up the content of the page. Such things as the dated updated, the author and the title are presented within the page data so that they are easily found.
When I popped over to Google Webmaster Tools I found that my new site was spinning warnings about missing data. So the template designer had wrapped my posted in the hentry class but had not included the other pertinent details that make up the complete (or expected) data set.
More information on hAtom and hEntry can be found at http://microformats.org/wiki/hatom-examples
Fixing hEntry Errors
To rectify this, I dug into the WP template code and added the following where necessary. It took some time to track the locations but essentially for my template came down to a file named content.php (used to display a single blog post) and another named loop.php (used on home page).
<div class="hatom-extra" style="display:none;visibility:hidden;">
<span class="entry-title"><?php the_title(); ?></span>
was last modified: <span class="updated"><?php echo get_the_date(); ?></span>
by <span class="author vcard"><span class="fn"><?php echo get_the_author(); ?>
</span></span>
</div>The style of the outer div is “display:none;visibility:hidden;” which means that the element is part of the page but is not rendered with the visual content.
This code block was added to the code within a div that had a class definition of ‘hentry’. Really the easiest way to determine this was to view the source of the page when rendered. This also served as a great method for performing trial and error when adding the above code.
Page (meta) data can be tested here https://developers.google.com/structured-data/testing-tool/
Fixing “Press This” and 403 Errors
I considered also becoming a content curator so started looking into the many different plugins that were available. Most that were free resulted in 403 errors with my HostGator hosted site. Reviewing some of the information available on Google I could see that it would be necessary for me to contact HostGator to have the Apache mod_security module adjusted. Most sites claimed that a rule would need to be removed, or the site itself would need to be whitelisted.
I decided to go with my own option and use the “Press This” element that was included with my WordPress install.
First and based on my research I could determine that the 403 error was due to the “Press This” element pushing ‘http://’ to the HG hosted WordPress site. So I needed to get around that to have any chance to resolve this issue without having to have HG adjust my (virtual) server’s settings.
Looking into the Javascript code associated with “Press This” (by selecting Edit) I could see that a parameter ‘u’ was being passed to WordPress to do the real work. Adjusting this to remove the ‘http’ seemed like a reasonable solution.
This
..."&u="+o(c)...became this
..."&u="+o(c).replace('http','')...I opted to strip only the ‘http’ since this would allow me to support both ‘http’ and ‘https’ URL passing. I would only need to add the ‘http’ back to the passed URL before it was processed on the server.
So previously with “Press This” I saw
press-this.php?v=8&u=http%3A%2F%2F...Now I was seeing in the popup window that resulted from pressing the bookmarklet
press-this.php?v=8&u=%3A%2F%2F...All that was left was to add the ‘http’ back to the URL, and to do that I only needed to take a look at the press-this.php script, which directed me to the class definition found in class-wp-press-this.php. Here I simply changed the line in the merge_or_fetch_data method
$value = $this->_limit_url( $value );to
$value = $this->_limit_url( ('http'.$value) ); // Robin hack to allow URL's to be passed inOf course I will have to be aware of any new version of WP which may overwrite my change. That’s one of the reasons I am blogging that here now.. 🙂
Ultimately a better solution might be to adjust the mod_security module, but for my use this is sufficient. In the end I may use the “Press This” bookmarklet on the odd occasion, it was the challenge that drove me.
I hope that this helps you too!