Greg’s Plugins for WordPress

Plugins for WordPress

Frequently Asked Questions About Greg’s Plugins

Photo by Horia Varlan - //
Photo by Horia Varlan -

Here’s a selection of the most frequently asked questions about Greg’s plugins for WordPress.

Notes for All Plugins

Plugin Support

I do not officially provide support for any plugins. I provide them for free in the hopes they might be useful, but without warranty or support of any kind. Having said that, I do often take time to reply to questions by email to help folks get the most from the plugins and from WordPress.

Very very very occasionally I stop by the discussion forum. Please do not expect a timely reply from me (or any reply) if you post a support question for one of my plugins there. I have enough things to keep organised in life — as I’m sure you do too — without trying to keep up with a zillion pages of forum buzz.

Custom PHP, CSS, XHTML or HTML 5 Coding

I do not provide custom PHP coding, custom CSS styling, or custom XHTML or HTML 5 coding.

Safe Wrapping of Plugin-Dependent Function Calls

When updating your theme with any function call that is dependent upon the presence of a plugin, it is good practice to wrap the call within a conditional that checks whether the function is available, as in the following:

if (function_exists('gtcn_basic_callback')) wp_list_comments('callback=gtcn_basic_callback')
else wp_list_comments();


if (function_exists('gtcn_comment_numbering')) echo gtcn_comment_numbering($comment->comment_ID, $args);

Don’t You Realise You’re “Doing It Wrong” With Variable Plugin Translation Domains?

Of course I realise I’m “Doing it Wrong”, as a few WordPress people think it’s funny to say: of course my translation domains don’t work! However, much of the code you see in my plugins is being re-used from nearly a decade ago when I first started working with WordPress in 2004. (You should try thumbing through a few popular plugins — or, even better, a few pages of WordPress core code — from back in 2004 just for fun, to get an idea of the context.) Back then, I didn’t realise that translation relies on the Unix gettext utility and has very little to do with PHP itself.

Unfortunately, the WordPress architecture encourages the mixing of code, content, and markup all on the same plate of spaghetti if you want to leverage translation. I’ve made the decision to forgo translation for the time being for the sake of not mixing together thousands of words of content with PHP code and HTML layout. Maybe one day I’ll go back and handle it differently, which is why I’ve left all those variables in translation domains even though I know perfectly well they don’t work; doing so will make it easier to bring everything up to spec for translations with a search and replace.

Frequently Asked Questions About Greg’s High Performance SEO

Where can I find more explanation of your brief replies given here?
This applies to all questions here: Please see the ‘Instructions’ tab of the plugin for full details. Yep, there’s a reason the plugin includes a six thousand word guide.
Can you tell me how I should fill in secondary titles or meta keywords or head descriptions? And what about all these settings — what should I put in the boxes?
First, some background… The plugin is designed with plenty of settings specifically to enable individual users to introduce variation, detail and — information theoretically speaking — complexity. To the extent that everyone uses the same configuration, that configuration ceases to be a meaningful differentiator. Simplicity and ‘just working’ are great qualities in many areas of life; search engine optimisation is not one of them. (By very very rough analogy, if you have a short password made up of only letters, that password is significantly weaker than a long one that includes letters and numbers and punctuation; by the same token, the less ‘jiggle’ room available to you in the form of meaningful settings, the lower the limit becomes on how much information your configuration can contain. The less information in your configuration, the less there is in that configuration to differentiate your site from everyone else’s sites.) Finally, to the extent that it is easy and straightforward to tell you what you ‘should’ put in this setting or that setting, that answer is low on information content. The upshot of all this? I cannot give you good answers as to what to put in this box or that setting without delving into your specific context in significant and time-consuming detail. I am not in a position to make that kind of investment of time into your site for you. If your site is a significant source of income or other reward for you, then it may be worth your while to invest your own time into learning about the ways you can leverage a plugin of this sort to help your site become even more successful. However, if your personal budget of time and effort in this area is more limited, then you may be better served by a simpler plugin with less potential information content.
Why am I seeing unexpected output — sharing links, JavaScript code, etc. — in the head meta description?
This is caused by a combination of two factors: 1) other plugins are clumsily inserting crud into the value of the_content returned by WordPress, and 2) you haven’t specified a head meta description yourself for the post in question (either by filling in the head meta box or by providing an excerpt). When you don’t provide a head meta description yourself, the plugin’s normal behaviour is to ask WordPress to let it see the post’s excerpt, and it does its best to build a description using whatever is given to it by WordPress. If you also haven’t provided an excerpt, then when WordPress is asked for it, it builds one from the first part of the post’s content. If another plugin is messing around with the post content by placing a filter on the_content, then what WordPress returns for the post’s excerpt is affected by the other plugin’s filter. (Using an actual template tag is a vastly more robust way of adding things to the final page output than layering filters over the_content, incidentally.) So, if you’re seeing this problem, the fix is either to 1) start writing your own meta descriptions, which is always always always going to be better than letting an automatic process do it for you, or 2) shut off the automatic insertion being done by some other plugin that is messing with the value of the_content.
Why am I not seeing the expected output of some other plugin — ShareThis, etc. — when GHPSEO is active?
Just as with the question above, this is due to plugins using WordPress filters instead of template tags to alter the page, and the method is fundamentally brittle and conflict-prone. To fix it, shut off the ‘automatic’ feature of whatever plugin is messing with your content and use a template tag instead — that way, you determine (via your theme) exactly where the other plugin’s output should appear, and you don’t have to worry about it creating conflicts with other plugins that are (ahem!) better behaved. There is a time and a place for using WordPress filters, and WordPress would not be the platform it is without them — but trying to use a filter to do a theme’s job is asking for trouble.
Why can’t I have my modified titles appear in WordPress menus?
The plugin is very deliberately designed not to mess with article titles but instead to provide modified versions via a template tag.
Why isn’t the plugin making any modifications to main titles?
Unless you’ve enabled Sledgehammer Mode, modified titles won’t appear unless you specifically include a function call/template tag in your theme.
What’s the difference between a secondary description and a meta description?
The latter goes in the head section of the page, while the former won’t appear anywhere unless you specifically include a function call/template tag in your theme.
Why can’t I see any secondary titles?
The secondary title will only appear if you specifically include a function call/template tag in your theme.
Why do I see errors when I enable Sledgehammer Mode?
Provided that no other plugin is using output buffering, you should never see errors as a result of using Sledgehammer Mode. However, plenty of plugins use output buffering, and a large proportion of them do it badly. Uncoordinated output buffering by many different pieces of code is a crazy way to build a page. So if you’re using Sledgehammer Mode — or any other type of output buffering in any other plugin — you run the risk of conflicts. The solution? Avoid output buffering like the plague, and use the provided template tags to put the output of GHPSEO right where you want it. (Briefly, the problem with output buffering is that the start point and end point of each example of output buffering need to be matched up, a bit like XHTML tags need to be balanced. If the end points don’t come in the right order relative to when the start points came, then all hell breaks loose. Since WordPress provides no mechanism for coordinating the potential chaos created by different plugins using output buffering, you roll the dice whenever you use it.)
Why doesn’t GHPSEO do anything special with titles or secondary descriptions for custom taxonomy archives?
Custom taxonomies are just another way of adding metadata to organise posts in different ways — exactly like post tags. In fact, without custom theme coding to take advantage of them, it is hard to see how custom taxonomies add much of anything that is not already present with built-in taxonomies like post tags. Therefore, doing somethng special with titles or secondary descriptions for custom taxonomy archives is almost always a theme-level task. However, the plugin also provides a full API to enable external code to modify its output in any way you see fit, so even if you choose to use exactly the same theme code, you can still set up your custom taxonomy modifications however you like via the API. Why not just add settings within GHPSEO for every possible custom taxonomy someone might want to define? Well, since developers can add an unlimited variety of taxonomies (one might say the taxonomy of taxonomies is infinite), it is impossible to create a ‘one size fits all’ set of configuration options for all possible custom taxonomies.
Why doesn’t GHPSEO offer special support for sitemaps?
If you believe it’s a good idea to turn over storage of your posts’ main titles to an SEO plugin, then making sure that your sitemap matches up with your SEO-tweaked main titles is probably a good idea; it’s probably even a good idea to integrate the two functions in some way. If you think that turning over storage of your posts’ main titles to an SEO plugin is madness, then sitemaps that simply work with WordPress’s own, built-in, reliable main title storage seems like a pretty good idea too; in that case, there is no need whatsoever to integrate SEO with the job of generating sitemaps.
Does GHPSEO support my favourite plugin X (insert name of favourite plugin)?
Generally speaking, GHPSEO is designed to support the core functionality of WordPress. I don’t spend a lot of time chasing after other plugins that require the addition of more code so as to interoperate with them. The vast majority of plugins don’t require it anyway, because they too are designed to support the core functionality of WordPress rather than striking out on their own. So, my suggestion always is this: try it. If it works, great. If it doesn’t, choose a different plugin than Greg’s High Performance SEO.
When enabling support for data left behind by other SEO plugins, why doesn’t GHPSEO take a full import of the other plugins’ data, rather than reading it on-the-fly?
Importing data (rather than reading it on-the-fly) is fine unless you want to give users the freedom to swap back and forth and try out different plugins — or even (shock, horror!) use more than one provider’s plugin at the same time — without worrying about keeping two or three or four different versions of meta information in sync. One of the fundamental design principles of Greg’s High Performance SEO is to avoid locking you into using any specific plugin.

Frequently Asked Questions About Greg’s Threaded Comment Numbering Plugin

Wait! I can’t find wp_list_comments() in my theme files! How can I use this plugin?
Not all themes have yet been updated to support the new comments function. You can check with the theme’s creator, or there’s an excellent tutorial available if you’d like to tackle the job yourself: Migrating Plugins and Themes to 2.7: Enhanced Comment Display.
How does Greg’s Threaded Comment Numbering plugin work for pingbacks and trackbacks?
The plugin will automatically detect and respond appropriately, depending on whether the callback function itself is handling all types of comments, just pingbacks, just trackbacks, etc.
What if I call the plugin functions from somewhere in my template other than a callback for the wp_list_comments() function?
The plugin is designed to work in conjunction with a callback function for wp_list_comments(), and it is only in that context that it will have anything to number.
Does this plugin work with versions of WordPress earlier than 2.7?
No. The plugin is designed specifically to work with new comment handling features introduced in version 2.7.
Why don’t the comment numbers look very nice with my theme?
As you can probably imagine, it’s impossible to ship CSS with the plugin that looks just right with every theme available. However, with a few tweaks to match your theme’s existing CSS, it should be possible to make the comment numbers match virtually any theme. (If you’ve read the ‘Instructions’ tab for the plugin or looked at the main ‘Configuration’ tab, you’ll know that the plugin’s default number styling can be enabled or disabled with the flick of a switch.)

Frequently Asked Questions About Greg’s Comment Length Limiter Plugin

If my theme doesn’t include wp_footer(), can I still use this plugin?
The plugin relies on wp_footer() to incorporate its inline Javascript into the page, so without that call, the countdown box won’t function.
The plugin’s counter box doesn’t count — what’s wrong with this thing?
Please be sure to read the plugin’s ‘Instructions’ tab to learn whether and how to modify your theme to ensure that the counting box works. (Some older themes require a manual tweak or two to help the plugin work as expected.)
Why does the counter box stop working when I use other plugins that provide AJAX functionality for my comments?
The ‘J’ in ‘AJAX’ stands for JavaScript, and JavaScript which replaces chunks of the page can either be DOM-respecting or DOM-trampling. Trampling the DOM (e.g., by using innerHTML) makes it easier for the programmer to replace chunks of the page, but at a cost: namely, no other piece of code can then reference elements within it. If the AJAX plugin you are using tramples the DOM via innerHTML or similar shortcuts, then neither this plugin nor any other plugin will work correctly when trying to use JavaScript to access elements within the part of the page that the other plugin is modifying. If you’re sure that the AJAX plugin you’re using does not trample the DOM, then the more likely cause of problems is that whatever the AJAX is inserting into your comment form does not provide the same structural cues that would otherwise be available to help the comment limiting code identify where a comment is being typed and how long it is.
What about comment_form — how do I use it in my theme?
The first stop on the comment_form tour is the Codex page on the function. The Codex also provides a wealth of information on making use of themes in general.
Why doesn’t the counter box look very nice with my theme?
As you can probably imagine, it’s impossible to ship CSS with the plugin that looks just right with every theme available. However, with a few tweaks to match your theme’s existing CSS, it should be possible to make the counter box match virtually any theme.