custom url structures for the Directory plugin

Hi,

We are running the WordPress Directory plugin over a subdomain based multisite.

This all seems to be working okay, and we are using custom code to populate the categories from the main category list.

The issue we are currently having is with the URL structure of the directory categories, tags, and listings.

Currently they take the form of:
sub.domain.com/listings-category/main-category/sub-category/ for categories
sub.domain.com/listings-tag/tag-name/ for tags
sub.domain.com/listing/listing-name/ for listings

We would like to simplify or customize this structure in one of a few ways.

Ideally we would like it such that the first subdirectory doesn't exist, e.g:
sub.domain.com/main-category/sub-category/ for categories
also ideally we would like to be able to stack these, e.g. such that a listing in the category 'blue' with name 'listing-one' would have the url sub.domain.com/blue/listing-one/

If this is not possible, or would require too much custom code, an alternative would be to have shortened url descriptors such as:
sub.domain.com/c/main-category/sub-category/ for categories
sub.domain.com/t/tag-name/ for tags
sub.domain.com/l/listing-name/ for listings

Again, if possible it would be preferable to be able to combine these, e.g.
sub.domain.com/c/main-category/sub-category/l/listing-name/ for a listing within a category.

Related to this, is it possible to not display top level categories when you are within a sub-category.
e.g. If you went to the category 'colours' followed by the sub-category 'blue', the url would be sub.domain.com/listings-category/colours/blue/
Is it possible to just display sub.domain.com/listings-category/blue/ ?

Please let me know if any of these are doable within the construct of the plugin.

Regards
SteveB

  • pxwm

    Hi Ari,

    We have done something similar with another directory written in php so we are comfortable doing this but we were hoping there may be some functions/hooks we could use to achieve the same results.

    Also if we do use .htaccess rules do we need to be aware of any implications in respect to the existing directory structure usage?

    Our understanding is that your Directory plug-in does not use .htaccess outside of the standard Wordpress provisions.

    Regards
    SteveB

  • aristath

    @pxwm

    We have done something similar with another directory written in php so we are comfortable doing this but we were hoping there may be some functions/hooks we could use to achieve the same results.

    No, unfortunately there aren't any that I'm aware of! Doing it manually in your theme would require you to write a bunch of custom template files and manually create some pages in your dashboard so it's not something that I would recommend.

    Also if we do use .htaccess rules do we need to be aware of any implications in respect to the existing directory structure usage?

    Our understanding is that your Directory plug-in does not use .htaccess outside of the standard Wordpress provisions.

    There are no special considerations to be taken into account... Some simple rewrite rules should do the trick!

    If you do implement these rewrite rules, I would love to see them!

    Cheers,
    Ari.

  • pxwm

    Hi Ari,

    looking into this further, I'm not sure if changing the url layout in .htaccess would be enough on its own.

    We might be able to set it so that sub.domain.com/t/tag-name/ gets resolved to sub.domain.com/listing-tag/tag-name/ when it is entered into the url bar, however the links that are generated on the page by the Directory plugin itself would still be the long form, as it gets these from somewhere within its own code. We would need to change it so that both the urls generated on the directory itself and the way the site resolves them are changed. Is it possible to change this in the plugin or via an external function, and if so where?

    Also, adding .htaccess changes to Wordpress seems harder than otherwise, because Wordpress uses simple .htaccess statements to manage its entire link structure, so simply forwarding /t/(.*) to /listing-tag/$1 breaks the whole site.

    Regards,

    SteveB

  • pxwm

    Hi Ari,

    Further update.

    We have tried to identify the code that is being used to generate the url structure, as we're assuming we will have to change some code as well as writing .htaccess rules, and we have grepped 'listings-category', 'listing-tag', 'permalink', 'pretty' across all the plug-in files and CustomPress, finding only one reference for 'listings-category' and 'listing-tag' in the data.php file in the core directory.

    Changing these values (in each case they are fed into an array with a key of 'slug') does not change the site's link layout. I assume this is because these array initialization functions are only called when the entry does not exist.

    Following from this, we then went into the database itself, searched and changed the values of 'listings-category' and 'listing-tag' to 'c' and 't' throughout, matching the changes we made in the php file. This had the effect of completely removing the categories and tags from the site frontend (listings were still visible). I'm not sure where else to look for changing these values, as it appears there is still a mismatch between the database and what the site is looking for, and would appreciate your support.

    Regards
    SteveB

  • Arnold

    You need to learn how custom post types work.

    http://codex.wordpress.org/Post_Types

    You need something in the URL to signal what you're looking for. Without the listign-category you couldn't tell the difference between the CATEGORY /blue/ and a TAG called /blue/. Since it's common for users to add their own tags you would run the risk of lots of collisions.

    The post types and taxonomies generate their own urls based on the settings when they are created. So if you wanted to have listing-category with a slug of "c" you need to go to CustomPress > Content Types > Taxonomy > listing_category > Rewrite and change the Custom slug from "listings-category" to "c".

    Of course the code has to change to match. It has to have some way of knowing what you mean.

    On your color/blue question On hierarchical taxonomies normally you need the path through the tree. You can flatten the url by Unchecking the Hierarchical URLs in the same box as above. Of course when you flatten it to /c/blue/ you run the risk of confusing things like

    /c/color/blue/ and /c/emotion/blue/ would both become /c/blue/

    The hierarchical url breaks ties like that.

  • pxwm

    Hi Ari and Arnold,

    Many thanks for the feedback.

    We've read the article and followed your advice and can confirm we have managed to set the categories to 'c', tags to 't' and listings to 'l'.

    However we did notice that when we selected the CustomPress Editor for categories and tags: CustomPress > Content Types > Taxonomy > (listing_category and listing_tags) > it didn't show any of the current settings whereas for listings it was fine. This meant that when we attempted to change settings in the Dashboard it overwrote a large chunk of the taxonomy and stopped it from working correctly.

    Is it possible you could check and confirm you get the same problem?

    In the interim, until you confirm if there is a problem with the Editor we have been able to change the taxonomy settings by changing the code in the data.php file from 'listings-category to 'c' in line 133 and from 'listing-tags' to 't' in line 91.

    We then removed 'listing_catorgory' and 'listing_tags' from: CustomPress > Content Types > Taxonomy > and then deactivated and re-activated the plug-in.

    This then enacts the if !exist statement in the data.php file so our url structure displays 'c' and 't'.

    We're still working on refining this but looks as though we are getting somewhere.

    Thanks again and would appreciate if you could confirm if you experience the same problem with the category/tag Editor in CustomPress.

    Regards
    SteveB

  • Arnold

    Don't change the data.php. It only runs on Activation and only creates the the custom taxonomies if they don't already exist. You should change them through CustomPress as a setting.

    Haven't had any problem with the editor. Went through the same thing as I wrote the last blurb. Most likely your editing damaged something somewhere.

    I would reload a fresh copy of the plugin. Delete the two taxonomies and then deactivate and reactivate the plugin so you get the defaults. Then make your changes in CustomPress. You won't lose any data.

  • pxwm

    Hi @Arnold,

    Many thanks for your feedback and guidance.

    To confirm we have followed your instructions and installed the Directory plug-in on a clean Wordpress single site installation and the CustomPress taxonomy Category/Tag Editor works fine.

    We then did the same but with a Multisite (subdomain based), and while the CustomerPress taxonomy Editor works with this at first with a single site, it appears to break when you have more than one site on the Multisite installation.

    I would appreciate if you could test and confirm our findings.

    Regards
    SteveB

  • pxwm

    Hi @Arnold,

    Many thanks for your feedback.

    To confirm the taxonomies will always be the same for every site we create.
    We designed it this way because we will potentially have many sites based on sub-domains.
    However there will be times when we want to add more categories/tags across all the sites so for ease of management we want to activate the plug-in at a network level.
    We have solved the problem of migrating the Category/Tag changes at the network level to synchronise them across all the sites.
    To confirm the CustomerPress taxonomy Editor breaks without this code being installed

    However this is were we are experiencing problems with the CustomerPress taxonomy Editor.
    When we have a number of sites created and select the CustomerPress taxonomy Editor at the network level it doesn't show any of the values that we original entered when setting up the plug-in.

    I would appreciate if you could confirm this is the case and if there is a way to resolve this.

    Regards
    SteveB

  • pxwm

    Hi Arnold,

    Many thanks for your feedback.

    To confirm, we are using the Taxonomies editor under Content Types from the Network dashboard, not from the individual sites. This is so that the changes will take effect over all sites that are part of the multisite.

    The issue is that when there is more than one site on the multisite, the Taxonomies editor doesn't work properly, losing all of the pre-populated fields and causing errors when it is saved.

    I've attached two screencaps of the Taxonomies editor.
    One when there is a single site (either standalone or on a multisite, and working) and then one when there is more than one site on the multisite and not working.
    To confirm if we remove all the sites except one on the multisite then the Editor will work again.

    Regards
    SteveB

  • pxwm

    Hi Arnold

    Good news.

    We may have rectified the problem by unchecking the top 'enable sub-site content types' field in the CustomPress settings on the main Network dashboard.

    To confirm with this checkbox unchecked the CustomePress Editor works.

    However we assume unchecking this box will not allow us to add categories/tags at a site level!

    Is there any reason why unchecking this box resolves the problem?

    Regards
    SteveB

  • Arnold

    If you are creating the custom type at the network level, then ONLY the editor at the network level should be used. Ifyou enable editing on the subsites they can ONLY edit a (potentially) duplicate of the same taxonomy. That's why your losing settings. Your looking at the subsites copy of the taxonomy not the network one. You cannot edit the networkwide copy from a subsite.

    Unchecking the 'enable sub-site content types' field forces everything to the network level.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.