Forum Replies Created
Nice catch, I didn’t even think of BuddyPress and it’s 220.127.116.11 version, nice catch Pascal 🙂
@oldshaghat Ha, there we go, on our bug tracker already, glad we were on the right path at least. Great either your workaround or the one mentioned in the ticket until fixed 🙂
$content_dir (from the constant ‘WP_CONTENT_DIR’) resolves as:
content_url gives mydomain/wp-content
and the file location starts out as :
That last path, I’d expect that to be
wp-contentwhich is before
Plugins are “typically” installed unto the
wp-contentdirectory, WordPress has some constants available to change these, typically
WP_PLUGIN_URLare not used anywhere near as much, maybe the Openshift configuration has these defined in the
wp-config.phpfile in the root directory?
This probably needs further investigation by bbPress, mainly to check the constants
WP_PLUGIN_URLso these can be used standalone when
WP_CONTENT_URLare not used at all.
@oldshaghat can you check in your
wp-config.phpif any of the above constants are defined please?
if it hangs up and I restart, should it continue from where it stopped?
Yes, with a caveat, if the importer is processing
100rows at a time, you may end up with some duplicates as it will re-import that chunk again.
The latest version of bbPress is 2.5.10, 2.6 will be the next major release and 18.104.22.168 does not, nor will probably ever exist…
They’re all available from https://bbpress.org/plugins/legacy/
bbPress queues up its CSS stylelsheet using WordPress’ standard functions
wp_enque_stylesheet()so it shouldnn’t cause any issues.
I’ve never tried Redhat’s Openshift, nor even knew it was a thing until now.
Do they use a “standard” copy of WordPress or is it modified somehow?
What versions of WordPress and bbPress are you having this issue with?
The “Notice: bbp_setup_current_user was called incorrectly.” will be caused by either your theme or a plugin.
Try switching theme to Twenty Fifteen to see if the error is fixed, if not deactivate all your plugins except bbPress and then reactivate each plugin one-by-one until the error appears again, then you’ll know which one is causing the problem.
What do you have your permalinks set to?
Did you run the “repair tools” to repair the forums metadata after your “manual import”?
Did you run the “bbPress repair tools” after importing?
If not, go to the WordPress Dashboard -> Tools -> Forums and run each of the repair tools
I think this is it: https://bbpress.trac.wordpress.org/ticket/2785
All those topics in those forums are “super sticky”
Go to topics dashboard https://example.com/wp-admin/edit.php?post_type=topic
On each of those topics in the list click “Unstick”
Your issue should be fixed now
There are a couple of “preview” plugins on GitHub
Let us know how they go 🙂
Thanks, that should be enough info for now, it eliminates fucky things that can happen with MAMP and XAMPP working with localhost, most likely there is a PHP restriction that is triggering this, can probably be worked around/ignored I think.
The importer restarting is a pain, can you check via phpMyAdmin or equivalent if you actually have a
wp_bbp_converter_translatortable? (Maybe a different prefix to
wp_if you use a custom prefix, e.g.
What I actually expect here rather than restarting the import is:
Conversion Complete Repair any missing information: <a href="https://example.com/wp-admin/tools.php?page=bbp-repair">Continue</a></p>');
Conversion Complete Started process again with Converting forums (0 – 99)
For now, can you run through each of the repair tools via and see how everything looks, it should fix up the counts of forums, topics, replies etc
@ darkoned12000 Thanks for the detailed reply, helps heaps +1
All those MySQL queries look correct, so what I see is you have 100-199 forums, it recalculated your forum hierarchy, you’ve 1100-1199 topics, there were some “sticky” topics, 1800-1899 topic tags, and 400-499 replies imported all up.
I’m surprised, aka have not seen before the
ini_setwarning shown in the conversion window, I thought you may have found that in your logs rather than on-screen :/
<Script started over again with ‘Converting Fourms’, I’ve never seen this happen either, what is the environment you are performing this in? A local setup using MAMP or XAMPP? A Vagrant VVV setup? A webhost suck GoDaddy, Dreamhost etc?
I’m trying to think how I might be able to replicate this issue so I can then fix it :/
noticed that it had created several duplicates of each forum area and replicated posts more than once. It’s almost like it didn’t know it finished and restarted the process all over.
Hmmmm, that is weird, especially the forum duplicates
Is there any logs or debugging that I can turn on
Right click, “inspect element” will show you the actual MySQL queries in the raw web page source code that are taking place that importer uses for each step.
If there is mods installed on IPB could this mess with the importer at all?
Possibly, I’ve not tested any of the importable forums with any mods, there are simply far too many permutations and combinations, the MySQL debug above should help with determining if this is a factor or not.
ini_setis bbPress’ attempt at bumping PHPs memory limit to 256mb if it can during import, you can ignore this.
WordPress database error Specified key was too long; max key length is 1000 bytes for query CREATE TABLE wp_bbp_converter_translatorissue I still need to fix, I’ll try to get that fixed today, see https://bbpress.trac.wordpress.org/ticket/2936
I’d start by deactivating other plugins and then reactivating them one by one to find the plugin causing the conflict:
This is now fixed and will ship as part of bbPress 2.6
It’s been a while since I tried it, I’ll have to re-attempt it in a couple of days when I have an opportunity to try it again.
As I recall, it imported the users fine, and then it looked like it was doing the posts, but after, I want to say about 150 posts, it froze there, never indicated further imports. When I checked the database tables, it didn’t appear that it actually brought the content from Dizkus over to bbPress at all.
Ok, so it did something, thats a good sign in that the database name and password were correct.
If you’ve ever used Chrome/Firefox “inspect” debugger, you can right click and select “inspect” or (view the source code of the web page) and there is some extra debugging MySQL statements you will see there, if when testing you have issues take a look at the last query and include that MySQL code here when posting back, it will help determine what went wrong.
As to the localhost problem, I mirrored the Zikula site to my local WIn 10 machine, and then tried to import on a local WP/bbP site and it didn’t do anything. Seems like it just couldn’t find data.
If it can’t find any data it should thrown an error message to that affect, if you don’t select
Dizkusfrom the dropdown menu on the importer screen and use the default
AEFthat can be one of the causes, another is that the database is not in the same database server as your WordPress install.
Did you import that database to your Win 10 machine or were you trying to connect to it remotely?
You’ll need to give us more information than “same too”, issues are rarely ever the same
What did you see that gave you the impression that it timed out?
What exactly did you say? Can you post a screenshot or something else to help identify the exact issue please?
@jon-fergus I think the reason could be that the forum is within a BuddyPress group
Also BuddyPress now has “group avatars”, will that do what you’re after?
@jon-fergus I suggest you do not add
edit_others_topicsto user roles so they can add inline images, it *WILL* allow them to *edit others topics** for whatever reason users cannot edit other topics as you suggest might be a bug, it might not be and maybe a conflict with your *adminimize hide dashboard* plugin and is obfuscated and easily bypassed.