[Plugin: Custom Content Type Manager] CCTM_PATH doesn't update going from localhost to live ser

I’m confused by this: the CCTM_PATH constant is set at run-time and it relies on your server to report the correct file directories. There’s nothing in the options table that is relevant to this: DO NOT EDIT anything directly in the wp_options table! The CCTM data is *serialized* data, meaning it’s not meant to be edited by humans (that’s just the way WP handles custom options). There’s nothing in there that stores the path anyhow. The only reason the CCTM_PATH is necessary is that unlike most CMS’s, WordPress neglects to set a path variable in its config file.

The magic happens inside wp-plugins/custom-content-type-manager/includes/constants.php:

define('CCTM_PATH', dirname( dirname( __FILE__ ) ) );

If your server is for some reason not reporting the directory correctly, you could manually edit that file, e.g.

define('CCTM_PATH', '/home/your-user/public_html/wp-plugins/custom-content-type-manager');

As a side note, WP is really not built to be migrated: it hard-codes nearly everything server-specific detail, and as you’ve noticed, editing serialized data is a recipe for disaster.

I’ve got exactly the same problem after a host migration. I’ve even tried hard coding the constant CCTM_PATH within contstants.php with no luck.

I get the following error:

Warning: require_once(/nfs/c02/h11/mnt/40992/domains/papermashup.com/html/wp-content/plugins/custom-content-type-manager/fields/textarea.php): failed to open stream: No such file or directory in /var/www/wp-content/plugins/custom-content-type-manager/includes/CCTM.php on line 1600 Fatal error: require_once(): Failed opening required ‘/nfs/c02/h11/mnt/40992/domains/papermashup.com/html/wp-content/plugins/custom-content-type-manager/fields/textarea.php’ (include_path=’.:/usr/lib/php-5.3.8/php’) in /var/www/wp-content/plugins/custom-content-type-manager/includes/CCTM.php on line 1600

the odd thing is after the host migration it’s still using the old path (as shown above):

/nfs/c02/h11/mnt/40992/domains/papermashup.com/html/wp-content/plugins/custom-content-type-manager

which should be:

/var/www/wp-content/plugins/custom-content-type-manager

Any ideas what could be the problem?

Ah… it’s gotta be the paths being cached. Did you export your definition on one site and then re-import it on the other? Or did you just migrate the database? Migrating the database wholesale in WordPress is often problematic (see https://code.google.com/p/wordpress-custom-content-type-manager/wiki/FAQ#My_Custom_Fields_Broke_after_Moving_my_Site!)

If you did the correct migration procedure and exported/imported the definition and you still are having problems, you should be able to do this:

1. On the original site, go to the Tools tab of the CCTM and clear the cache.
2. Go to the CCTM’s Tool’s menu and Export the definition.
3. Migrate your WordPress files and database as per usual.
4. On the new site, revisit the CCTM’s Tool tab and Import the CCTM .json definition file created on step 1. Without directory scans being cached, then PHP should rescan your directories and re-calculate the paths to your various files.

The goal is to get a fresh install on the new site… if you have to, you may have to nuke the row in the wp_options table where option_name = ‘cctm_data’. If that gets into your new location, it will contain the cached directory scans and you’ll have trouble. E.g. in phpMyAdmin or a MySQL command line, you can run a query like this on the new site (after you’ve made backups of your database and your CCTM definition):

DELETE FROM wp_options WHERE option_name='cctm_data';

And then you can import your .cctm.json definition file. But don’t mess with the database unless you absolutely have to.

Let me know if that works. If the problem with paths occurred after exporting/importing a definition file, then we need to file a bug report because the definition should not have exported the cached directory paths (since they won’t be relevant in a different location).

Actually, this does bring up an edge case that I need to handle. https://code.google.com/p/wordpress-custom-content-type-manager/issues/detail?id=441

Thanks for your quick response!

I’ve fixed the problem. I use Pagodabox.com for hosting so it’s not easy uploading content into wordpress once deployed as everything is managed via GIT.

This is what i did to fix the problem:

1. First I took a DB backup and exported the CCTM definition (important)
2. I then copied the ‘cctm_data’ form the database and did a find and replace to replace the old path with my new one.
3. After logging into WordPress i noticed all the Custom Content Types had gone. (have no fear)
4. For some reason the upload feature doesn’t work for the import tool but that could be due to my setup, but thats no problem.
5. I simply re-added the content types and everything seems to work just fine

Would a suitable fix for the plugin be the following.

Every time you activate the plugin it could re-check the path URL’s from the database match the server paths. This means that even if you migrate your database as soon as you re-activate the plugin in WP it’ll refresh the DB entry.

Thanks for the fix though, very helpful!

Ashley

You stepped into a classic problem with the way WP stores data:

2. I then copied the ‘cctm_data’ form the database and did a find and replace to replace the old path with my new one.

Because WP serializes data, doing a find-and-replace will nearly always corrupt your data. See the CCTM’s FAQ where this is discussed in detail.

4. For some reason the upload feature doesn’t work for the import tool but that could be due to my setup, but thats no problem.

That was probably due to permissions on your upload directory, so you’ll have to check with your host. You will probably encounter other hiccups with WP in general if this is the case (e.g. adding images will probably fail too).

See https://code.google.com/p/wordpress-custom-content-type-manager/wiki/FAQ

The fix suggested would not work, but I know where you’re coming from: the reason the paths are stored is to cut down on server load since scandir can cause a spike in CPU and/or RAM. Scanning the directory paths to see if they match the actual paths would defeat the purpose of caching the directory scans in the first place. I’m going to implement some options to deal with this in https://code.google.com/p/wordpress-custom-content-type-manager/issues/detail?id=441

WP’s architecture is pretty poorly conceived when it comes to server migration IMO, so it’s a rough ride for any plugin riding on that ship — WP is the only CMS I know of that does not have a configuration setting for its base path and URL. Those critical flaws crack wide open when swapping servers, unfortunately. Sorta condemns WP to “non-serious sites” for most of my projects… I’ve gotten flamed for that, but that doesn’t fix the problems, but I digress.

OK – what do you do if you migrated the site before you exported the CCTM definition and now you can’t go back to the old host/site to export it and follow the directions above? Apparently I did exactly the wrong thing – migrated the site, imported/exported the database, manually edited the wp_options table with the new URL (my new hosting company provided a “preview” site I could look at, with a different URL). I edited the db back so it is now the same URL as it was previously, but I suspect I corrupted the data somehow.

BTW, I followed the directions MediaTemple, my new hosting company, provided in order to update that database. I plan on telling them their directions can cause serious problems! https://kb.mediatemple.net/questions/1556/Migrating+your+websites+to+the+%28gs%29+Grid-Service#gs

The problem isn’t really Media Temple’s fault: it’s WordPress. It has a critical and severe design flaw… there’s really no good way to avoid problems given the way WordPress stores its data.

If you don’t have a backup, there’s probably not much you can do other than manually recreate the definitions.