Plugin Update: Category Template Hierarchy 1.3
Posted: March 12, 2012 Filed under: Plugins | Tags: bug report, category template, parent category, plugins, query template, software-development, wordpress Leave a commentDownload Category Template Hierarchy Version 1.3 from the WordPress Plugin Repository
I’ve release an update to the Category Template Hierarchy plugin, a particular bug report prompted the update but there are a couple of other changes as well.
I use this plugin for three sites I’ve worked on for Sears / Kmart, so over time I make minor changes to resolve issues I notice or improve how it works, but I don’t always have time to release those changes publicly.
A recent bug report forced to release a fix, and gave me an opportunity to update the plugin. Some of these changes effect how the plugin behaves, so it could impact your site if you depend on this plugin to keep your theme working. Here are the changes
- Improved performance be removing completely unnecessary logic to determine current category while building the list of potential templates to use. (No behavioral effect)
- Changed the filter used by the plugin. Before it used the very broad and general ‘template_redirect’ filter, but that caused obvious problem with other parts of the hierarchy, so not it uses the ‘category_template’.
- In addition to changing which filter is being used, the plugin used to `include()` the `get_query_template()` function, but now returns `locate_template`. This should resolve a bug where global variables such as $post were not available from within the loop.
- Logic in the `is_child_of_category()` and `is_parent_of_category()` has changed to check `!isset($child_category->parent) || !isset($parent_category)` instead of `empty($child_category) || empty($parent_category)`. This could effect your code if you use these conditional tags for anything in your theme.
The only item that does not effect any behavior is #1. Items #2 and #3 change the way the template hierarchy effect other parts of the native Template Hierarchy, so if you’ve seen strange behavior with non-category templates then you’ll definitely benefit from these changes. Item #4 is important as well, since it simply makes the conditional results much more accurate.
I don’t know how often people use the conditional functions, or how many of the couple thousand people who’ve downloaded this plugin actually use it at all – but I really appreciate the bug reports and any feedback. As I’ve said, I use these plugins myself on productions sites – so the public QA is always appreciated.
Download Category Template Hierarchy Version 1.3 from the WordPress Plugin Repository
Enjoy!
Simple Hook Widget – WordPress Plugin
Posted: December 14, 2011 Filed under: Plugins Leave a commentDownload: WordPress Plugin Directory
This widget allows the user to insert a hook, with a name of their choosing, in any sidebar.
The hook can be anything, an existing hook from the WordPress Core, a plugin, a theme, or something you’ve come up with on the fly. Once the hook exists, your plugins, your theme, or the WordPress Core to make something happen with that hook.
This can be used in conjunction with other more complex plugins, to give the user control of then things occur (yes, that is intentionally vague). It can also serve as a quick alternative to making very simple widgets tied to code from a theme. Say you have a chunk of code which already exists on your site, you’d like to also have it placed in a sidebar, but don’t want to make a widget out of it (since its entirely theme-centric). You could simply hook this chunk of code to a custom hook and use the Simple Hook Widget to place that custom hook in the sidebar. This is absolutely not an endorsement toward that strategy for widget development, but there may be times where such on option is useful to a developer in a pinch.
This widget also contains an internal hook, which will be your hook, prefixed with simplehookupdate_. So if you use this plugin to create a hook name ‘testhook’, the widget, aside from creating the ‘testhook’ in the chosen sidebar location, will also create a hook called ‘simplehookupdate_testhook’. This hook occurs within the update method of the WP_Widget class, immediately before $instance is returned.
All in all its very simple, and intentionally so. I hope developers can find some useful uses for it – I know I already have a very complex plugin in the works that will utilize this. Please feel free to make suggestions or ask questions.
Moving the Uploads Directory in WordPress
Posted: August 23, 2011 Filed under: WordPress Development 19 CommentsTo give context, I will start from the beginning,… If you’ve come here simply looking for any way to move the uploads directory – skip all this and jump straight to Moving the Uploads Directory…
Moving wp-content
There are many times when its a great idea to move some of the default locations of certain directories in WordPress. At my current job, we have a handful of sites that all share a the same plugins and theme folders. However, when I arrived at this position a few months ago, they had done this by using symbolic links – this causes problems with many plugins due to their use of the __FILE__ magic constant. As a result it was necessary to modify many of the 3rd party plugins we had remove that constants use.
In WordPress we can change the default location of the wp-content folder by defining a couple constants in wp-config.php as explained in the Codex:
define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content' ); define( 'WP_CONTENT_URL', 'http://example/blog/wp-content');
Plugins can be moved similarly as the same section in the Codex explains. What happens here is we are simply telling WordPress where we want to put wp-content or plugins, rather than confusing the issue by having it point to a directory where they wont be via symbolic links.
This is extremely useful, by doing this we can share our plugins and themes across multiple instances of WordPress without having to push code out and maintain each one individually. Moreover, many if not most developers using source control on multiple environments probably already ignore wp-config.php – or at least have some way of distinguishing environments within wp-config.php.
Moving the uploads directory…
While discussing the necessary changes in wp-config with team members, I realized we might run into a hitch with the uploads directory, which resides within wp-content. While we wanted to share plugins and themes, we certainly did not want to share content.
Initial googling resulted in no clear documentation as to how to move the uploads folder out of wp-content – and the codex page describing the the way to move wp-content makes no mention of either themes or uploads. So while I considered the possibility of leaving wp-content where it was, and moving themes and plugins, I could not find a way to move themes out of wp-content. I eventually found that we could filter the wp_upload_dir() function, or that we could update the ‘upload_path’ option – but both of these methods would require a plugin which would need to be maintained in source control, need to be turned on, and need to have an interface to allow a human to add the correct information depending on the environment. This to me seemed like a lot of work for something that started out with 2 lines in wp-config.php – not only that but it makes the entire exercise pointless, as there is already an option in the general settings to manually change it. A manual change is not what we needed. There had to be some other way.
Eventually I made my way through the core code to find out that there is an undocumented constant called UPLOAD which wp_upload_dir() checkes for – if its defined it will used it, if its not it will create a path by combining WP_CONTENT_DIR (which as we saw above, we can define in wp-config) with the ‘/uploads’.
define( 'UPLOADS', '/wp-content/uploads' );
Theres a catch though, when UPLOADS is actually used, its added to the end of ABSPATH. Defining ABSPATH one fo the first things WordPress does, its a constant which houses the WordPress root. By tying UPLOADS to ABSPATH, it means we can’t move the uploads directory outside of the WordPress folder structure.
A patch…
As a result of this, I decided to write my first ever patch for the WordPress core. The initial patch creates WP_UPLOADS_DIR and WP_UPLOADS_URL, so that the uploads can be defined via wp-config.php just like wp-content and the plugins directory. It defines those constants in the same way also, in default-constants.php – I then simply modified wp_upload_dir() to use these constants rather than hardcoding a definition each time the function is run.
It seems to be a simple solution and would be a natural extension of the method for moving wp-content and plugins.
The debate…
Reaction to my humble patch was not enthusiastic as you can see by reading the comments on the ticket #18489. After som protracted debate with Nacin and some others on the #wordpress-dev IRC channel, I identified what seems to be the primary concern – that developers might mistakenly begin to use the said constant within plugins instead of using wp_upload_dir() as they should, and that its availability would create confusion since in many cases it would not have the correct path (wp_upload_dir has many condition related to multisite as well as the font-end option that overwrite the default, and that would also overwrite the new constants.)
A possible solution…
As a result of that debate in IRC, I have modified the patch so that it does not define the constants by default, but stead works the same way the little-known UPLOADS constant does – simply allow wp_uploads_dir() to check if they have been defined – if they have, then it will use them, otherwise it will use use WP_CONTENT_DIR . ‘/uploads’;
eddiemoya 