[Resolved] Types breaking past version 1.0.4

[Author]

Posts

[Schroeder]

My issue is this: when I attempt to either add or edit a custom post type, I get to the point of pushing "Save Custom Post Type" ... and then I see a white screen, with a url similar to the following (stays the same as before I click the button, but displays a blank white page):

hidden link

It should be displaying something like this:

hidden link

Has anyone had an issue like this before, or know what might be happening? I don't believe that the issue is within Types, WordPress, or a theme or plugin. I've tested this on more than 10 sites, and every site hosted on Firehost does exactly the same thing (nothing), and every site on Bluehost or GoDaddy hosting (similar sites with the same base theme and plugins, but varying versions of Types and WordPress, going back to just the last version of each), creates the post type correctly.

Version 1.0.4 is working normally, but versions 1.1.3.1 and 1.1.3 are both breaking on my Firehost server.

Please help! I'm in the middle of a project that has been shot to hell because I tried deleting and re-adding a post type before I was aware of the extent of the problem.

[Caridad]

Dear Jon,

Can you try enabling WP_DEBUG in wp-config.php? We should then get a proper error message instead of a blank page.

Please let me know if there is anything else that I can assist you with.

Regards,
Caridad

[Schroeder]

Thanks, Caridad.

I've set up a clean wordpress installation, fully upgraded all around, at cleaninstall.redfishbluefishmedia.com. The only plugins installed are Types and Akismet, and it's running a default theme.

I've enabled WP_DEBUG like so...

define('WP_DEBUG', true);

However, I don't see any error text showing up. Is there somewhere other than on-page that I should be seeing it? I'd be happy to give you direct access to the WP installation if you'd like to see it.

[Caridad]

Dear Jon,

Can you with the Debugging PHP section in the following address?
https://toolset.com/documentation/user-guides/debugging-types-and-views/

Maybe we get a better error message in error_log.txt.

Also, have you ask you hosting about this?

Regards,
Caridad

[Schroeder]

I have asked my host (Firehost) about it, but they weren't able to give me much of an explanation. At the time when I asked them about it, my assumption was that some changes we'd just made to the server were causing the issues. Ultimately, we did a full server rollback, in part because of this error. Later, I discovered that the error seems to occur only on my sites hosted by Firehost, and only on those running a version past 1.0.4. I'm currently hosting sites on Bluehost and on GoDaddy, and neither of those seem affected.

I've temporarily fixed the issue on my Firehost sites by using the earlier version (1.0.4) of Types; however, I'm a stickler about keeping everything up to the most current version if at all possible.

In wp-config, I added the following code (starting with enabling WordPress debugging):

define('WP_DEBUG', true);

define('WPV_LOGGING_STATUS', 'debug');

ini_set('log_errors',TRUE);
ini_set('error_reporting', E_ALL);
ini_set('error_log', dirname(__FILE__) . '/error_log.txt');

However, after running through the process again (and seeing the blank screen), I'm not seeing anything either in the console or in any of my folders (an error_log.txt file doesn't seem to be generated).

My apologies; I know that's not helpful. Thanks again for your help, Caridad!

Oh -- to add to what my host had said, from our exchange, they gave me the following errors (however, I don't know precisely where these came from, since I assume they didn't go through the same process of attempting to create a post type). Here's what they told me:

--------------------------------------------------

As to the white screen in the taxonomies page, we briefly enabled debug mode in wordpress to ensure that we had proper error output. Below is the output wordpress normally suppresses when posting to that page:

Notice: Undefined property: RTE::$debug in /home/a553/public_html/wp-content/plugins/rich-tax-description-editor/i8/class.i8Core.php on line 17

Notice: Undefined property: RTE::$options in /home/a553/public_html/wp-content/plugins/rich-tax-description-editor/i8/class.i8Core.php on line 542

Notice: Undefined offset: 2 in /home/a553/public_html/wp-content/plugins/rich-tax-description-editor/i8/class.i8Core.php on line 167

Notice: Undefined offset: 1 in /home/a553/public_html/wp-content/plugins/rich-tax-description-editor/i8/class.i8Core.php on line 167

Notice: Undefined offset: 2 in /home/a553/public_html/wp-content/plugins/rich-tax-description-editor/i8/class.i8Core.php on line 167

Notice: Undefined index: action in /home/a553/public_html/wp-content/plugins/rich-tax-description-editor/i8/class.Plugino.php on line 74

Notice: Undefined index: HTTPS in /home/a553/public_html/wp-content/plugins/simple-301-redirects/wp-simple-301-redirects.php on line 143

Notice: Undefined variable: control_ops in /home/a553/public_html/wp-content/plugins/all-in-one-slideshow/all-in-one-slideshow.php on line 46

Notice: Undefined property: RTE::$pages in /home/a553/public_html/wp-content/plugins/rich-tax-description-editor/i8/class.i8Core.php on line 282

Notice: has_cap was called with an argument that is deprecated since version 2.0! Usage of user levels by plugins and themes is deprecated. Use roles and capabilities instead. in /home/a553/public_html/wp-includes/functions.php on line 2722

None of these are deemed critical by apache or php and thus the page returns a 200 and no errors end up in the logs. Hopefully they will be helpful in diagnosing the root cause of the issue. From what I can see, this is not an issue with any configurations on the servers themselves.

[Schroeder]

(The error messages above do refer to plugins which are not installed in the installation I'm looking at now; this was on a live site where I couldn't easily disable the remaining plugins or go back to the default theme).

[Caridad]

Dear Jon,

Do you have the mbstring extension enabled in PHP?

https://toolset.com/forums/topic/blank-page-when-adding-new-post-type/page/2/#post-29990

Regards,
Caridad

[Schroeder]

I don't know whether it's enabled (and being a front-end kind of guy, I don't actually know how to find out); I've put in a ticket with my host. If it's not, should it be?

[Bigul Supporter]

Hi Jon,

You can use following code for debugging. It will store errors & notices in /wp-content/debug.log file. Please let me know your PHP version, Server OS and WordPress version.

define('WP_DEBUG', true);

// Enable Debug logging to the /wp-content/debug.log file
define('WP_DEBUG_LOG', true);

// Disable display of errors and warnings
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);

---
With Regards

Bigul

[Schroeder]

Upon installing the mb_string extension, the plugin appears to be working normally on my clean install! Thanks for the terrific support; I don't know how I'd have ever gotten to this answer on my own.

I'll let you know if there are further issues or anything else, but it appears to be fixed.

Thanks!