I’d have to have access to your server to troubleshoot it… I didn’t change anything fundamentally with the database or the queries in the recent releases. There’s a new version on the dev-branch @ http://wpcctm.com/cctm-dev.zip — I’d really need to know what else your site is running and see your system logs. Do you have access to the MySQL slow query log or to the Apache error logs?
The site is hosted on a web host so I don’t have access to the logs (I asked and they said no).
I do recall some weird behavior after updating CCTM; the menus for the custom types disappeared from the WordPress admin menu, the custom type content was no longer showing (got 404 errors) and one of the custom types’ variables became duplicates of another custom type (i.e., the custom type named ‘widget’ had it’s slug, menu name, optional variable, etc. changed from ‘widget’ to ‘sprocket’ after the update).
To fix those issues I changed the menu position for each (there’s 3 custom types) from 26, 27, 28 to 30, 31 32, fixed the slugs, menu names and re-enabled the /%postname%/ option (they were disabled during update for some reason).
Do any of these update issues indicate a possible source for the database slamming?
Yeah, the menu items blinked out for some people because the data structure changed, so editing and re-saving the definitions fixed that (because it forces the data into the new structure) — see http://code.google.com/p/wordpress-custom-content-type-manager/wiki/Upgrading094 . But none of that would account for your database getting “slammed”. If you can’t see the logs for your server, then it’s almost impossible to diagnose this, and there’s no way to verify or disprove whether the CCTM is responsible for it… without logs, it’s just stabs in the dark, unfortunately.
Disabled CCTM 0.9.4.1-pl for 24 hours and the site stayed up and the second I reactivate CCTM 0.9.4.1-pl the site goes down again! ACK!!! How do I downgrade to 0.9.3.3? Just rename/remove 0.9.4.1-pl and install 0.9.3.3 manually?
Yeah, any time you downgrade a plugin, you click its delete link, then install the older version. 0.9.4.2 is the latest version — I think I fixed the issue that some people were having, but I haven’t been able to duplicate the issue on any of my servers. Sorry you’re having troubles, but I can’t troubleshoot your server, and if your hosting company won’t provide logs, neither can you. Who’s your host?
IX Web Hosting (http://www.ixwebhosting.com).
Was that new data structure added in version 0.9.4 or 0.9.4.1-pl?
0.9.4 uses an improved data structure. Personally, I would never sign up with a host that couldn’t provide me with logs. Most WHM/cPanel shared hosts will at least let you look at shared logs.
If you can give me FTP and WP access to your site, I might be able to look into it, but without logs, that’s pretty much a JV server option, unfortunately, and I wouldn’t expect professional results from it.
I can’t do jack about the host, its what the client already had when I started working with them.
I’ll look into getting you access. Thanks for your support so far. The main reason I went with CCTM over the other custom type plugins is because you were the only one who regularly updates it.
Actually, if I downgrade to 0.9.3.3 after updating to 0.9.4.1-pl will 0.9.3.3 even work (because of the different structures)?
If you downgrade, you’d have to re-define your post-types and custom fields. If the older version works, then stick with that, but I don’t have bandwidth to support anything but the current version.
Re the host and clients: it often saves a lot of time and $$$ to change hosts. Clients don’t like it, but it’s ridiculous to save $5 a month when it costs you $250 in dev time to troubleshoot it. It usually only takes an hour or so to transfer a WP site.
Man, I can relate to the authors of the other plugins: I get a LOT of emails about this thing, some of them nice, some of them not so nice, only a small fraction of them lead to any paying work, and the amount of donations couldn’t hope to pay for even a small portion of development. I have a full plate of other gigs, so I’m just glad I’ve been able to shepherd some of them into using this plugin and funding its development.
Frack me! I really don’t want to start this whole thing over. As great as this plugin works its still very tedious and laborious to set everything up.
So there’s no way to downgrade without re-defining the post-types and custom fields? (I’m a decent PHP/MySQL developer and willing to modify/hack CCTM’s code or database tables/columns/data to facilitate an easier downgrade to 0.9.3.3)
New development: spoke more with the web host techs and apparently its WordPress thats freaking out and throwing the HTTP 500 error. Whenever I activate the CCTM plugin the website and WordPress backend does down with the above error. To fix that problem I have to manually deactivate CCTM directly from the database (wp_options table -> active_plugins row -> remove “i:3;s:37:”custom-content-type-manager/index.php”;” from the text in the option_value column/field) and the site and WordPress backend comes back up.
Does this new development help?
P.S. – Also I updated to 0.9.4.2-pl and same HTTP 500 error occurred :/
NEW new development: It appears memory is the issue. WordPress runs out of memory trying to run CCTM. I had to increase WP’s memory usage to 64 MB (originally 32 MB) to get CCTM 0.9.4.2-pl to run (added “define(‘WP_MEMORY_LIMIT’, ’64M’);” to wp-config.php, before the set of database configs).
So within this environment CCTM requires 7.02 MB of memory to run. Yikes! Furthermore it takes an extra 4 to 18 seconds for a page to start loading. Double yikes!! It was previously thought that this delay issue was caused by something else but now I know its actually CCTM :/ (the same delay issue also occurred when I tested this site on another web host provider). I assume 0.9.3.3 didn’t require nearly as much memory as it ran just fine when 32 MB was the limit (still had the same delay issue though).
So problem solved, but unfortunately I learned CCTM is a memory hog and is causing my massive delay problem *sigh*
Thanks for sharing this info. Please, accept my apologies if my plugin is causing you problems. As a developer and someone who uses stuff like this daily, the last thing in the world I want is to have my code cause problems instead of fix them. But I’ve found that coding and maintaining a plugin is really way more work than I ever expected. There are always edge-cases that you just don’t expect.
The load times sound painfully slow. I don’t have a server with that little memory, but I know 500 errors can be caused by memory leaks/shortages (many of the newer CMS packages like Drupal 7 or MODx 2.x require *lots* more memory). Even modest shared hosts usually offer 64mb or more for PHP, so again, this might be better to run on a beefier host. This one is really hard for me to test, though… I don’t have access to a configurable dedicated server, and PHP’s memory usage is pretty unpredictable… more practically, usually clients just care if the plugin works on their server, not on anyone else’s.
CCTM is certainly part of this, but I suspect part of it is also your host. I haven’t spent much time optimizing the code just because I’ve learned through painful experience that premature optimization is the death of any project. The feature-requests are still coming in and I’m jostling the data structures to support it. But I’ve architected this plugin to work *with* WP instead of trying to reinvent the wheel… one guiding principle was not to build custom database tables and to have the plugin “fail gracefully” in the sense that if you uninstall it, things would still work as much as possible (granted, WP won’t recognize custom post-types unless some plugin recognizes them, but this stores data in the wp_posts and wp_postmeta table, just like WP itself does).
If you could hook me up with FTP (or preferably SSH access) to your server, I might be able to zero in on where the plugin is slowing down. This isn’t 100% scientific in the same way that a debugging suite is scientific, but at least it’d help me identify the bottlenecks and improve the code accordingly.
No need to apologize, I completely understand. This is the nature of free software! I’m inclined to give you FTP access (the web host doesn’t offer SSH access) but I’m really puzzled how any troubleshooting or debugging can be done by looking at the PHP files – they’re the same exact copies as the distribution ZIP. Plus there’s some security concerns being that this is the client’s production site. I have a good hunch that the CCTM delay issue occurs even if there’s no content (it did before), so I can set up a WordPress installation with all the same plugins on my web host account and give you access to that for debugging if you want (SSH, MySQL and FTP).
Let me know if that works for you. If so, shoot me an email (crashintoty [at] gmail.com)
