kisshomaru

To be clear, (working as is), I have it installed in /root/wp/ with a /root/index.php that has one line only:
require(‘./wp/wp-blog-header.php’);

The /root/.htaccess has, among others, something like this (so it goes to /wp/…):
RewriteRule ^(wp-(content|admin|includes).*) wp/$1 [L]
RewriteRule ^(.*\.php)$ wp/$1 [L]
RewriteRule . index.php [L]

ok, working, I had some issue in restricting stuff not coming from example.com in my .htaccess file and was going around in circles quite a bit, fortunately I disabled the plugin and saw the same issue so I figured it out.
It does work with multisite installed in it’s own folder not in root.
Thank You.

This is a perfectly valid wordpress multisite installation since 3.5 (I see the plugin says it is compatible up to 4.0). See this:
https://codex.www.ads-software.com/Giving_WordPress_Its_Own_Directory
So, it is not really a sub-folder, the entire wp is in its own folder under /root/wordpress/. The domain is going directly to https://www.example.com but everything is redirected to root/wordpress/ as per the link above.
I am using subdomain mode normally with all subsites (NOT both sd and sf). It is now that I need to map a different domain to the xxx.example.com when I came across this issue.
Would this plugin work with this perfectly valid multisite installation?

Sorry for the big delay.
The scripts did not show anything in the db, so it might be just a bug.
I can give you access to my personal site in progress where I have this reproduced, Jeff, let’s take this offline.
Is there an email I can find you?

Hi Jeff, sorry for the delay. I had time to retest latest ver.
Still the same issue. It will not delete old entries, but does delete new ones. Was it using different database tables/entries a few versions ago? (after 3.0 I mean but before this fix). Because it applies some old settings since 3.0 to the pages and that is beyond my control no matter what I try (more info: this is a multisite, maybe there are different tables?).
So the problem is that even if I delete the plugin with no retention option and reinstall, problem is back: some pages are getting applied some old policy.
What should I look for to delete manually?

I did not have time to try it yet, but I will hopefully do that in the next couple of days and will probably close all issues if they are solved.
Thanks.

Oh, and 3rd, there still are some PO in the options table remaining as well, namely the ones related to mobile agents, and some https, fuzzy and stuff. Others are deleted.

I found the bug.
There are a couple of them actually. Basically it is because I don’t have a clean setup, not even after deleting the PO db records in options table. I guess it is more to it than just that.
1st bug: The plugin does not delete its records of posts and pages after disable with “No preserve”, probably more than just that. What I saw is this: I had at some point one of the previous 3.x versions enabled for posts and pages, so there were settings there for the particular page I am referring to. After reinstall with “No”, the posts and pages settings are back. That would be the first bug.
2nd bug: When disabling CPT support for posts and pages, the settings remain as they were set, instead of relying on permalink filters and global settings only.

So first, I need a way to delete all records, or an upgrade to a PO that can delete itself completely. Then I can try again.

Solved in 3.2.2. Thank You Jeff.

I saw this a number of times and I do not believe it to be related to PO per say. It all depends on the exact error, but for me in particular, I noticed that WP revisions of pages/posts are also keeping records of the modification made to the old PO table. So if you restore, modify, delete a revision, compare or otherwise tinker with an older revision, an error will be thrown that that table does not exist.
Jeff can probably confirm that.

I believe this is a bug. I did that. The field in DB is populated properly if I modify something after I enable the plugin.
But, if I remove every check box from there and save, the db field is complete empty and the CPTs are not displayed anymore at all (upon refresh of the settings page – immediately after save it looks ok) (should be displayed as unchecked).

Hmm. But that is the thing. I did re install the plugin from scratch. Then when I got in to settings, posts/pages were there checked, so I removed, saved, then the issue appeared.

I think there were two places that I saw with the hardcoded wp_ on a quick search in the same lib\PO class file. But can’t be sure if that is everything.
Thanks for the tip with the options table. Is there anywhere else (any other table) you are inserting data? I need to clean this manually before I retry anything.

OK, first bug that I found is in the lib\PluginOrganizer.class.php at line 1228:
$sites = $wpdb->get_results( $wpdb->prepare( "SELECT blog_id FROM wp_blogs" ) );
The problem is that wp_ does not exist for me. The database prefix should be queried from wp or supplied separately by user.
(One can and most should change the prefix). So yes, I have different prefix – same for all tables.
I quick search through your source files for wp_ shows this as a hardcoded value in more than one place.

I am unable to start from scratch. Deleting the PO with or without the preserve settings will leave everything in the database (so when I add it back everything is still there, hence, I believe, the errors for me).
How can I safely purge the database from all PO related entries before reinstall?