Forum Replies Created
I can confirm the quoted method works using bbPress 2.6 RC 7.
I’m grateful for the help.
Correction, As soon as “bbPress private forums” is Activated…
As soon as “bbPress private forums” is enabled, all “Hidden” forums are listed (visible), even when “Click to activate forum visibility” is off.
For my use case, I’d like to use the “Remove Private prefix” option, but no other options are needed.
If you instead go to Dashboard>Forums>Edit and a set “Visibility” to “Hidden”, the forum is still visible (listed) to a user with the Forum Role of “Participant” (although they cannot visit the forum).
Can you confirm? This isn’t the expected, default bbPress behavior for a “Hidden” forum according to forum visibility documentation.
By “default” I mean bbPress without “bbp Private Forums” installed. I understand you are the author (awesome job!). If “Hidden” actually hid a forum, I wouldn’t require “bbp Private Forums” and I’d skip the need to donate to you :).
Turns out if replies have no corresponding topic, that will cause the above symptoms (I can add one more symptom, the CPU on the server spikes until memory is exhausted). A manual, binary search through the Forums was used until what was causing the search issue was isolated.
Thank you for your help. Your reassurance the database wasn’t too big was helpful to keep digging for root cause.
Hi Robin. Thank you for responding.
database size should be no problem
I’m glad to hear that, thank you.
This is a custom convert that is a work in progress.
Forums, Topic, Replies all look good, along with a single word search, but we just noticed this issue with searching more than one word.
Another clue, after enabling debug output, “sometimes” a two word search will give this error:
“Fatal error: Allowed memory size of bytes exhausted in /opt/bitnami/apps/wordpress/htdocs/wp-includes/post.php on line 2272”In reply to: General Migration Questions
As Robin pointed out (thank you), “My SQL Workbench” is likely the tool or at least a starting tool. I’ve tried its “Migration Wizard” going from a MS SQL database, but unfortunately the wizard errors out on MS ntext fields that contain 4 byte unicode characters (the error is “Inserting Data: Incorrect string value:” on the MySql side) despite both src and dst database fields having utf8mb4 as the character set, and even ensuring all of MySQL database connections are utf8mb as per here.
Since it is not too practical to try and filter out the offending 4 byte unicode chars, so as an alternative now I’m trying saving the src data to CSV and importing CSV on the MySQL side – but apparently the CVS libraries disagree on encoding/decoding – the dst table ends up with more records than the source, not sure who is a fault.