Support » Plugin: Attachments » Attachments not working on certain content types after upgrade

  • Resolved jbx


    I have noticed that after upgrading from the previous 1.x version to version 3.x adding attachments to the custom content types of other plugins (such as Events Manager) doesn’t work any more. I modified my theme to use the new PHP code and old custom posts work fine. However when I post a new item the admin screen does not show me the attachments upload controls any more for these content types.

    I’ve looked a bit around and found some doc about ‘custom instances’ here but its a bit confusing because it seems that their purpose is to have custom data attributes. So no idea what I have to do to re-enable attachments on the Events Manager plugin and other content types. I just wish to re-enable it on all of them as it was before. I don’t want any custom data attributes or anything.

    What do I have to do to get it working as before?


Viewing 5 replies - 1 through 5 (of 5 total)
  • OK, so after doing some piecing up of information I managed to fix this, although the documentation is not that clear (might be useful to update the doc). These are the things I deduced, would appreciate if I get a confirmation that I didn’t mess something up without knowing.

    1. The new Attachments (v3) plugin by default only works on ‘posts’ and ‘pages’. So the moment you upgrade, other content types (such as ‘events’ from the Events Manager plugin) will not offer you the facility to add/update attachments from the edit screen.

    It would have been more intuitive if there was a simple settings screen where one could select the content types to be mapped to the default instance (rather than messing up with PHP code).

    2. When you upgrade from v1 to v3, all the images attached to the current posts and content types will go to the default ‘attachments’ instance. It is not clear whether they can be moved to another instance.

    3. If you add your own instance settings as described in the doc, you will end up with 2 instances on the main posts and pages, and one instance on the custom post types (which I don’t want because the old attachments are now on the default ‘attachments’ while the new attachments will be on the new one). However, it seems that if I name my own instance ‘attachments’ the settings I pass override (or merge with? no idea) the default ones.

    Also watch out for the mistake in the PHP code in the first line of the function given in the example. Should be: $fields = array(
    not $fields => array(.

    4. You have to know your content type names to put them in the PHP code. (No idea why it was assumed that we would know the actual internal names of content types of plugins we install, a settings screen with the list of content types would have helped!). I happened to have a plugin Custom Content Types installed, which lists them all, so I could copy their names and put them in my functions.php.

    Plugin Author Jonathan Christopher


    Sorry you found the documentation lacking. The core purpose of this plugin isn’t really to extend other plugins but instead allow you to customize your theme using your own Posts/Pages/Custom Post Types.

    1. Correct, the default instance supports Posts and Pages because those are core post types. A Settings screen is in the works but is very low priority at this point as I’m focusing on the code base.

    2. This is incorrect. As per the instructions during migration you have full control over which instance name and which field names are used.

    3. Yes, you can technically override the default instance if you’d like, but as per the instructions you can disable the default instance if you’d like. Thank you for the heads up on the typo, I’ll get that fixed in the next release!

    4. As per number 1, the core purpose of this plugin isn’t to fill functionality gaps people find with other plugins, but instead set up their own custom implementations. You’ve illustrated the exact process one should take when extending a CPT they haven’t set up though. A Settings screen might be implemented in the future but I am focusing completely on the code and not settings screens at this time.

    Thanks for the feedback, it’s much appreciated.

    Hey Jonathan, thanks for replying!

    Re 2, understood. I had upgraded Attachments to v3 and migrated before I upgraded wordpress to v3.5, so I probably left everything default especially since the purpose of custom instances seems to be custom fields.

    Can you clarify if once you migrate, and all the attachments with the current posts are associated with the default ‘attachment’ instance, can they be moved (after migration) to another instance? When I tried to add another instance the attachments I already had (which were migrated automatically) remained attached with the old one, and the new instance just displayed another widget underneath (in the edit post screen). I was afraid to disable the default instance because the blog’s attachments would disappear.

    Re 1 and 4, I don’t completely agree with the approach though. Custom content types could come from our own plugins, but more often than not, people install other plugins. In this particular example I was using a custom content type from Events Manager which is brilliant, just like Attachments plugin is. It would have taken me ages to develop an events manager myself to just have attachments to events.

    The only issue here is that before (in v1) it used to work with all content types, and after upgrade the attachments edit field disappeared. It gave me quite a scare 🙂 but in the end I managed to piece things together. Maybe the migration script (for people who havent yet upgraded), could take care of checking which content types v1 is currently associated with so that the upgrade is at least backward compatible. I got even more confused because when I upgraded Attachments v3 remained working fine (due to the deprecated v1 branch), and then when I upgraded wordpress itself the problem occurred, which threw me completely off because it was working fine with v3.

    Plugin Author Jonathan Christopher


    The trouble with devoting so much extra time to edge case migration features is that the time (in my opinion) is better spent adding features to the new version. I don’t mean to sound harsh so please don’t take it that way, and I realize the documentation is pretty extensive and there’s a bit of a learning curve, but version 3.x does *way more* than 1.x with the only real loss at this time being a visual way to dictate which CPTs are enhanced.

    Given that, we need to take a step back and look at what’s changed in 3.x and see how that applies to what 1.x used to do: version 1.x applied the same meta box to any CPT you decided to support. Version 3.x now has a ton of custom attributes, and the ability to add multiple meta boxes. So I can’t make a blanket decision to apply all of the settings everywhere because everyone’s implementation is different.

    The migration script is meant to be a one-time thing; many people choose to ignore all of the documentation, the tooltips, and the instructions during the migration itself. Once the data has been migrated it’s in the new format, so opening the door for multiple migrations would result in a ton of data duplication (the migration script doesn’t delete legacy data (on purpose)) so I don’t think facilitating subsequent migrations is a wise use of time at this point either.

    I completely get that extending existing plugins with Attachments might be a high percentage of use cases, and I do plan on elaborating the Settings screen itself to make things a bit easier to implement, but a lot comes down to custom instances which each have custom properties, and how the UI for choosing which instance goes with which CPT plays out is a pretty complicated matter. Leaving it all in the code forces implementations to be intentional as opposed to global, something I much prefer. It’s not too difficult to determine what CPT name a plugin is using for it’s functionality, so extending them should continue to be pretty trivial, as you’ve discovered. I don’t mean to suggest that devs should rewrite every plugin they might want to use Attachments with, sorry it came across like that.

    I truly appreciate your feedback and will definitely take it into consideration, but this is only the second request for CPTs in the settings screen and there are a number of things I’d like to focus on before that. I haven’t had anyone request subsequent migrations either, but maybe I could put together a separate plugin that does just that (migrates a version 3.x instance to another version 3.x instance) and at the same time keeps it separate from the plugin itself. I’d love to get more feedback on that as other people might find it useful, but perhaps only after a borked migration attempt in the first place.

    OK dude, no worries.
    Users who get stuck have this post to help them too :).

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Attachments not working on certain content types after upgrade’ is closed to new replies.