Home / Topics / Events Maker / Bug & Error Reports / Post_Type Conflict

Post_Type Conflict

We're here to help.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • 28 April 2015 at 19:35 #6465
    splinters
    Participant

    I’ve had problems with Events Maker after installing it in place of another plugin. I tracked it down to be poor choice of the custom post_type – “event”. It’s best practice to use a prefix when adding a custom post type to ensure that it is unique, e.g. “em_event”, thus minimising possible conflicts with other plugins (which is exactly what is happening).

    I suggest you fix this ASAP as it’s a potential time bomb waiting to explode.

    On the positive side, congratulations on a very nice plugin with a feature set that doesn’t come free in other events management plugins.

    Geoff

    28 April 2015 at 21:52 #6466
    Bartosz
    Keymaster

    Thanks for the suggestions Geoff.

    Event though you’re right about CPT name prefix and possible conflicts, I doubt there is any possibility that you use 2 plugins doing exactly same thing (event management).

    So the EM post type name is intentional and it’s not a subject to change in the future.

    29 April 2015 at 04:52 #6468
    splinters
    Participant

    Hi Bartosz,

    It isn’t uncommon for someone to replace one brand of event manager with another – I’m sure you hope that it happens a lot in your favour :)

    The problem occurs even after removing a plugin, since it may leave the data intact so that a deletion and re-install of the plugin doesn’t lose all of the associated data. I can tell you that Event Organizer uses the same CPT as EM and after deleting EO and installing EM, I see spurious remnants of the events created with EO.

    WordPress Codex clearly states that every effort should be made to create CPTs that are unlikely to be duplicated by another plugin. Given the number of events management plugins around, “event” is a risky name for a post type.

    Quote:
    “Without namespacing your custom post type identifier, other post types in your website will more likely conflict with custom post types defined in a theme you fall in love with later or a plugin you realize that you absolutely need to use. Or if you are developing custom post types or themes there is a much greater chance your plugin or theme will conflict with custom post types defined in other plugins or themes and/or custom post types defined in your prospective user’s website. Namespacing your custom post type identifier will not guarantee against conflicts but will certainly minimize their likelihood.”

    Regards,
    Geoff

    29 April 2015 at 11:19 #6471
    Bartosz
    Keymaster

    Hi Geoff,

    And thanx for sharing your point of view.

    Again, I agree with you on one hand. You have a good intuition – there is kind of competition between plugins to take over the namespaces. You know Event Organiser post type name, WooCommerce uses “product”, EDD “download” and so on. You wouldn’t say these plugins are not developed with WP coding standards in mind (to be true, these are among the best examples of coding in WP).

    I do care about good practices and the way EM works internally (CPTs, metadata, custom taxonomies instead of custom tables) should make WP purists (like me:) more than satisfied. I just believe in an alternative way of thinking about naming conventions, that didn’t even focus on competition. I can’t recall the article name or the authors behind it but it’s all about standarizing post type names – event for events, product for products etc. with an option to switch the plugin that utilizes the functionality behind it. That’s an idea, hard to do, but maybe possible in the future.

    Best regards,
    Bartosz Arendt

  • Author
    Posts
Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.
Featured In