fireproofsocks

Sounds like Outlook may be filtering messages. Per the email, your license was used on 5 sites: all domain variants and install locations count against the limit.

You have already contacted me directly, so I’m not sure why you would post here for the public. As I said in the email to you, each unique install counts as an install, be it in a sub directory, sub-domain, or on a separate domain. I upped your license count to avoid spending more time on this. If that does not work, then you can purchase a new license key.

Remember: it’s pay-what-you want. If you don’t think dev time is worth your money, then probably it’s better for both of us if you find an alternative.

Please file this in the bug-tracker if it’s not there already – https://code.google.com/p/wordpress-custom-content-type-manager/issues/list
I don’t police the forums.

Do it in Google Code for now — I may have to re-create the Github repo so it rebases and gets the SVN history correctly. We still have a month or two before Google shuts down Google Code. Thanks for asking.

I just released 0.9.8.4.

Installing a new version of the plugin should not touch the database. Move the problematic version of the plugin out of the plugins/ directory so that its files are not included. Drop the new version of the plugin in (or install via the GUI). Activating should not nuke the database values, but the recommended practice here is to keep a backup of your content and field definitions (CCTM Tools menu –> export).

If your post type and field definitions are really gone, you can view the post types that are in the database via the CCTM Info page (there’s a graph there), and there is a wizard in the fields tab that can scan for existing custom fields, but that doesn’t restore all possible options, it only can get the correct names back in place.

In future versions, I’m moving the configuration out of the database: it’s too unreliable in there and problematic during migrations.

Could you file this in the bug-tracker please? Thanks: https://code.google.com/p/wordpress-custom-content-type-manager/issues/list

Please file a bug report: https://code.google.com/p/wordpress-custom-content-type-manager/issues/list

I do not police the forums. Thanks.

Marcel: 0.9.8.2 contains the stuff that should have been in the 0.9.8 release before SVN fartbarfed on it. Sorry, when it’s hitting the fan and I know a release has broken sites I tend to skip the mundane.

Sorry, SVN is making my life hell this morning. One file went AWOL in the release. I’m pushing up 0.9.8.2 — TBD if the WordPress repo molests it.

Yeah, sorry — I just pushed up a new version. It’s a rough ride getting this to migrate from git to subversion. I can’t figure out why the loader.php file went missing.

I’m pushing up 0.9.8.2. SVN is making things incredibly difficult and stressful this morning.

Yeah, sorry — I just pushed up a new version. It’s a rough ride getting this to migrate from git to subversion. I can’t figure out why the loader.php file went missing.

Try pulling down 0.9.8.2. There are some CSS fixes in there too.

Unfortunately, it’s not that simple: WordPress can be installed in a subdirectory, so justing knowing the path of current script doesn’t tell you where the WP app is or where it is relevant to the web root (i.e. the URL).

Plugin conflicts are nearly impossible to avoid in WP given its architecture and total lack of logging. Still waiting on funding to come up to address features like this.

Next version will address this (there is a feature request already: note that I don’t consult the forums as a guide to development). Unfortunately WordPress makes dealing with paths incredibly difficult because it does not offer configurations or functions for determining paths of critical parts of the app — it’s the only CMS I know of that omits these features, so the CCTM has to work around the limitations.

There is an FAQ to assist in migrations.

If you want to see features implemented more quickly, please make a donation.