• Resolved fabianadipolo

    (@fabianadipolo)


    When updating to the last version of CCTM the following fatal error occurs

    Warning: require_once(loader.php): failed to open stream: No such file or directory in /home4/xxx/public_html/xxx/wp-content/plugins/custom-content-type-manager/index.php on line 110

    Fatal error: require_once(): Failed opening required ‘loader.php’ (include_path=’.:/usr/php/54/usr/lib64:/usr/php/54/usr/share/pear’) in /home4/xxx/public_html/xxx/wp-content/plugins/custom-content-type-manager/index.php on line 110

    I have to deactivate the plugin.

    Is there a solution?

    Thank you

    https://www.ads-software.com/plugins/custom-content-type-manager/

Viewing 4 replies - 31 through 34 (of 34 total)
  • I’m out of ideas. What you are describing is technically not possible. There must be something we are missing out here. Without looking at the environment debugging is not possible any further. Maybe anybody else has an idea.

    Good luck.

    Hey all –

    Ran into this same issue, and finally figured out a fix. The problem is that the busted version of the plugin improperly modified the “cctm_data” JSON block (option_value) in the wp_options table (*note: table name may differ, if you’re using a custom or random db table prefix)

    So IF you happen to have a database backup from before this unfortunate incident, then restore it somewhere else other than your production environment (personally, I copied the raw MySQL files for the db in question to my local machine, and added them to my local MySQL install – but don’t restore the db to your live website, or you’ll lose ALL updates to your website since that backup!!), and do a search in your “wp_options” table for the option_name of “cctm_data”. Grab the “option_value” contents (a large JSON block) from that entry. Then go to your production environment, lookup the same value and replace the contents with the block you recovered from the backups.

    And that should fix things in the admin.

    Note that I believe that it shouldn’t matter how long ago your database backup was made – as long as you haven’t changed the custom content types / fields that you’d previously declared since the backup in question was created.

    …and if you have no backups of your website – then that’s a whole other problem in and of itself… but it’s probably possible to hand-reconstruct the proper entry from the existing (bad) one. I’ll leave it to the author or someone else to figure that out, though, if that’s really needed by someone.

    Hope that helps!

    twykr.

    Thanks twykr. Unfortunately, it didn’t seem to resolve the issue.
    I went into my cctm_data file and grabbed the information I had from the back up and plugged it in, but I just can’t seem to get rid of this error.

    Hey garyweldy –

    I went into my cctm_data file …

    Just to be sure – you grabbed the block of code from your database backup, and not a file, right?

    Also, make sure that the database backup you used is old enough. I believe the backup would need to be, at a minimum, over a week old (8+ days old or older) to contain the missing data that you need.

    Hope that helps ??
    twykr

Viewing 4 replies - 31 through 34 (of 34 total)
  • The topic ‘Error when updating to the last version’ is closed to new replies.