Hi @sabinooo,

I think wpDiscuz files are damaged on your server. We've never faced with such a weird issue. It's supposed to be WordPress 5.3 version issue. Could you please clone your website into some sub-domain using the Duplicator plugin then update to the latest WordPress version?

Thanks Tom,

*

As you recommended, I tested with a basical blog in a subdirectory, and for that one, wpdiscuz 7.2 works.

*

Minor progress, fixing an issue with another blog plugin that is used to add syntaxic colouring to raw html editing windows stopped Wpdiscuz7.2 causing a full site-breaking critical error, https://wordpress.org/support/topic/if-your-plugin-is-going-haywire-click-here-for-the-fix-jan-2020/

However... Wp-discuz 7.2 still breaks the site's pages, although now not to the point of generating a fatal error that breaks the entire site in its entirety, now it's only white pages for individual posts that possess a comments field.

Wp-supercache and cloudflare were cleared and in development mode, of course.

And, basically, in the error log, there's this super weird issue that the query to create additional database tables only work WITHOUT the final DEFAULT CHARACTER SET COLLATE bits O_o

mod_fcgid: stderr: WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'COLLATE' at line 1 for query CREATE TABLE `wp_wc_feedback_forms` (`id` int(11) NOT NULL AUTO_INCREMENT, `post_id` int(11) NOT NULL DEFAULT 0, `unique_id` VARCHAR(15) NOT NULL, `question` varchar(255) NOT NULL, `opened` TINYINT(4) UNSIGNED NOT NULL DEFAULT 0, `content` LONGTEXT NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `unique_id` (`unique_id`), KEY `post_id` (`post_id`)) ENGINE=MyISAM DEFAULT CHARACTER SET COLLATE ; made by activate_plugin, do_action('activate___wpdiscuz7.2__/class.WpdiscuzCore.php'), WP_Hook->do_action, WP_Hook->apply_filters, WpdiscuzCore->pluginActivation, WpdiscuzCore->activateWpDiscuz, WpdiscuzDBManager->dbCreateTables, maybe_create_table, referer:  https://www. [redacted]/wp-admin/plugins.php
mod_fcgid: stderr: WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'COLLATE' at line 1 for query CREATE TABLE `wp_wc_users_rated` (`id` int(11) NOT NULL AUTO_INCREMENT, `post_id` int(11) NOT NULL DEFAULT 0, `user_id` int(11) NOT NULL DEFAULT 0, `user_ip` VARCHAR(32) NOT NULL DEFAULT '', `rating` int(11) NOT NULL, `date` INT(11) UNSIGNED NOT NULL DEFAULT 0, PRIMARY KEY (`id`), KEY `post_id` (`post_id`), KEY `user_id` (`user_id`)) ENGINE=MyISAM DEFAULT CHARACTER SET COLLATE ; made by activate_plugin, do_action('activate___wpdiscuz7.2__/class.WpdiscuzCore.php'), WP_Hook->do_action, WP_Hook->apply_filters, WpdiscuzCore->pluginActivation, WpdiscuzCore->activateWpDiscuz, WpdiscuzDBManager->dbCreateTables, maybe_create_table, referer:  https://www. [redacted]/wp-admin/plugins.php
Followed by tons of "mod_fcgid: stderr: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in " entries.

Screenshots: https://imgur.com/a/4ZI65oB

You're right, something is off.

*

The default database encoding on the server is utf8mb4, so that part should be OK.
Adding (they were not present by default, it's an oooooold blog, that went through several hosts and started in the era where Latin1 was still the norm) define( 'DB_CHARSET', 'utf8mb4' ); and define( 'DB_COLLATE', '' ); to wp-config didn't change anything.

*

Afterwards (not before, after), I made a test, just in case, as I saw a discrepancy: the default character set is utf8mb4, utf8mb4_general_ci in phpmyadmin, while the already existing wpdiscuz tables, inherited from the earlier versions of the plugin, are currently in utf8_general_ci.

I told to myself "who knows, maybe converting everything to the very same encoding, ut8mb4, might help", but four wpdiscuz tables cannot be converted, error 1071, too long key (screenshot: https://imgur.com/a/MveNo0c ): wp_wc_avatars_cache, wp_wc_comments_subscription, wp_wc_phrases, wp_wc_users_voted, so that test ended before finishing.

*

That's as far as I can go myself, does that help, and yet I'm willing to help, do you have any suggestions?

Ok, thank you for the details @sabinooo,

We'll need login as admin, install the phpMyAdmin plugin and fix wpDiscuz database issues on your website. Can you please provide admin access to the website? If so please send it to info[at]gvectors.com email address.

Hello Tom, and thank you,

If access to PhpMyAdmin is necessary, I can grant that, allright. I'm sending the email in just one minute, with the information.

If more is needed than is offered in that mail, LMK.

Have a good day!

Hello again, thank you for helping!

I would be eager to know what you have done to create the tables (run the same query without the final collation method?).

Unfortunately, I'm terribly sorry to say that didn't fix the problem.

Trying to explain my testing without making it confusing:

- I've made use of the "official" database, of the live site using wpdiscuz 5, and a second database, onto which I cloned the site's database, to test that second one with wpdiscuz 7.

I would selectively update wp-config.php to make the site use the official database, or the clone.
During the testing, Cloudflare was in development mode (no caching at all), while wp-supercache was deactivated.

In the site's wp-content/plugins/ directory, there would be a directory "wpdiscuz5.3.5", and a directory "wpdiscuz7.2", allowing freedom of choice to activate either of them.

I would also check the site's apache error log after every change was made.

- Starting point, the "live" database, with wpdiscuz 5. Works. Nothing is added to Apache's error log over 20 minutes.

- I edited wp-config.php to make the blog engine use the second database. In there, in wp-admin, I deactivated wpdiscuz 5, and then activated wpdiscuz 7.
Trying to open any page of the website that contains a comment field: dead page with the "critical error" message, here's a screenshot... https://imgur.com/a/WfADldZ

In apache's error log, nothing appears in relation to that error.

However, tons of entries with "mod_fcgid: stderr: PHP Fatal error: Allowed memory size of 402653184 bytes exhausted (tried to allocate 2097160 bytes) in /home/..." appear in apache's error log. Apparently, most of the, if not every visitor doing anything with the site, now generates this in the logs.
Here's a screenshot: https://imgur.com/a/lsz0XAH
I tried increasing the maximum memory PHP is allowed to use, at the beginning it was just 128 MB, I tripled it, the frequency of those errors remained the same. Adding a "define('WP_MEMORY_LIMIT', '384M');" in wp-config.php (there was no memory limit mentioned before) didn't change anything either.

- I tried several times, made sure Cloudflare caching was off, that the wp-supercache plugin was deactivated. I went in wpdizcuz 7's configuration pages (the configuration pages DO work, it's only the blog pages with a comment field, that are dead), and changed every changeable option.
I also deleted the directory with wpdiscuz 7, to reupload a clean, freshly downloaded copy.
Still the same situation, it works with wpdiscuz 5, not wpdiscuz 7.

*

I'm open to every kind of testing of experimenting you want to do, as I would be eager to help solve that issue, would you have something in mind, hopefully?