Custom post type archives with WordPress Cuztom Helper

WordPress Cuztom Helper now enables custom post type archives out of the box.  In the same way that posts are shown on their own archive with archive.php, custom post types will use archive-{post_type}.php .

I decided to add this feature because one, generally, wants to be able to view all the posts of a custom post type. So if you have a custom post type named ‘Acme Products’, you can view all the products of this type by visiting example.com/acme-products/ in the browser.

In WordPress, custom post type archive pages are not enabled by default when you register a post type. If we left it like this in WordPress Cuztom Helper, one would either have to create a page template manually


/* Template Name: Custom Post Type Archive */

//somewhere in the template file 
global $query_string; 
query_posts($query_string . "post_type=YOUR-CUSTOM-POST-TYPE&post_status=publish&posts_per_page=10"); 
if ( have_posts() ) : while ( have_posts() ) : the_post();

and then create a blank page, choose the template and publish it, which is a lot of unnecessary work just to view posts of a custom post type. Or one would set

'has_archive' => true

while registering a custom post type. When has_archive is set to true, the custom post type slug is used for the archive page by default, which is a little unintuitive because acme_products/ makes more sense than acme_product/ when you want to view more than one product of Acme Product post type (it’s an archive page and not a single page).

There is an additional benefit to this i.e. saving the trouble of having to deal with slugs manually. Instead of trying to figure out slug_to_view_all_acme_products, you simply register your Acme Product post type and this will be done for you. In exceptional cases, such as for a custom post type named Music or Country Music where it makes sense to use the post type slug as archive slug, you simply set

'has_archive' => true

and your archive will be accessible at example.com/music/ or example.com/country_music

And when you want to disable the archive, simply set

'has_archive' => false

One just doesn’t have to deal with slugs unless one wants to use something drastically different. Another advantage of using archive over writing a Page Template is that one doesn’t have to create an archive-{post_type}.php page unless one is using custom taxonomies or metaboxes. Simply, the existing archive.php file be used. One also doesn’t have to use query_posts unless absolutely required.

So, from now on, custom post type archives are turned on when registering Custom Post Types with WordPress Cuztom Helper, as the default behavior. There you go. Download WordPress-Cuztom-Helper and take your custom post types to the next level with archives.

Install CakePHP in a subdirectory of WordPress

Let’s say you have a WordPress installation which is accessible in the browser at example.com and you want to install CakePHP in a sub-directory (or a directory inside a sub-directory) within WordPress so that it is accessible at something like example.com/cake/ or example.com/project/cake/ in the browser.

To achieve this, you need to modify the .htaccess files used by WordPress as well as CakePHP. I’ll explain how to modify .htaccess files in the following steps.

Step 1: Modifying .htaccess file in WordPress

In the directory where WordPress is installed ( in the same folder as wp-config.php file ), edit the .htaccess file and add the following line, assuming that your CakePHP subdirectory will be called ‘cake’

RewriteRule ^cake/(.*)$ /cake/$1 [L,QSA]

so that your .htaccess file looks like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteBase /
 RewriteRule ^cake/(.*)$ /cake/$1 [L,QSA]
 RewriteRule ^index\.php$ - [L]
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteRule . /index.php [L]
</IfModule>
# END WordPress

If your ‘cake’ is going to be inside another sub-directory of WordPress installation called ‘project’, then this line should look like:

RewriteRule ^cake/(.*)$ /project/cake/$1 [L,QSA]

If you don’t do this step, visiting example.com/cake/ or example.com/project/cake/ will try to open as a WordPress page which, obviously, isn’t right and will fail.

Step 2: Modifying .htaccess files in CakePHP

After completing Step 1, you will need to add the following RewriteBase statement in the .htaccess files used by CakePHP. If you don’t complete this step, your CakePHP app will show up but fail to load CSS / JS or any other assets in /app/webroot.

RewriteBase /cake

So, first of all, navigate to /cake/ or /project/cake/ , whichever is your CakePHP folder and edit the .htaccess so that it looks like this:

<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteBase /cake
 RewriteRule ^$ app/webroot/ [L]
 RewriteRule (.*) app/webroot/$1 [L]
</IfModule>

Then navigate to the ‘app’ folder inside ‘cake’ and edit the .htaccess file so that it looks like this:

<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteBase /cake
 RewriteRule ^$ webroot/ [L]
 RewriteRule (.*) webroot/$1 [L]
</IfModule>

Finally, navigate to webroot folder inside this ‘app’ folder so and edit the .htaccess file so that it looks like this:

<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteBase /cake
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteRule ^(.*)$ index.php [QSA,L]
</IfModule>

That’s it. You’re good to go.

Visiting example.com in the browser will open your WordPress website, while example.com/cake/ or example.com/project/cake/ , depending on how you configured it, will open your CakePHP app.

Bug fix for undefined variable notice in CPT-onomies 1.1.1

CPT-onomies WordPress Plugin by Rachel Carden enables you to use your custom post types as taxonomies and create relationships between your posts by using custom post type post titles as taxonomy terms, in a similar fashion as you would create taxonomy relationships.

Since it is not yet possible to create relationships between custom post types like that with WordPress, out of the box, I am using CPT-onomies v1.1.1 for a project that I’m presently working on.

While playing around, I stumbled across a bug which introduced a debug notice in the WordPress dashboard and didn’t let me publish or update posts for those custom post types which used a cpt-onomy (custom post type as a taxonomy). I reported it to Rachel and she responded quickly with a fix.

CPT-onomies v1.1.1 bug

Until a new version of the plugin comes out with the fix, to get rid of the debug ‘Notice’, you can change line 931 of manager.php in the plugin root directory from:

'cpt_onomy_archive_slug' => ( isset( $cpt_settings[ 'cpt_onomy_archive_slug' ] ) && !empty( $cpt_settings[ 'cpt_onomy_archive_slug' ] ) ) ? $cpt[ 'cpt_onomy_archive_slug' ] : NULL );

to

'cpt_onomy_archive_slug' => ( isset( $cpt_settings[ 'cpt_onomy_archive_slug' ] ) && !empty( $cpt_settings[ 'cpt_onomy_archive_slug' ] ) ) ? $cpt_settings[ 'cpt_onomy_archive_slug' ] : NULL );

This will remove the notice and you’ll be able to publish or update posts of custom post types which use a cpt-onomy without a hassle.