Eric McNiece

For Version: 1.2.5.0:

• /user-access-manager/class/UserAccessManager.class.php: Line 1533
• /user-access-manager/class/UserAccessManager.class.php: Line 1536
• /user-access-manager/tpl/adminSettings.php: Line 141
• /user-access-manager/tpl/adminSettings.php: Line 262

Files:

• UserAccessManager.class.php
• adminSettings.php
• FULL PLUGIN, patched – v1.2.5.0

@gm_alex – any chance we can get a timeline for a fix for this? Low-hanging fruit for at least 7 support forum issues…

Thanks Alex, I missed that construct – how long has that been in there?

Commenting out $this->_aPostableTypes[] = $oPostType->name; definitely removes the access widget from custom post types, so I can confirm that custom post types are supported in this regard. Beautiful!

I would be interested in hearing from OP about whether they have upgraded their plugin yet.

cannap is right – custom post type support is a long-running feature request. We need to re-add our custom post type slugs to the said $_aPostableTypes array every time the plugin is updated, unfortunately.

Alex: you seriously rock, this plugin is great! Do you have any plans to add custom post type support? Would it be helpful if somebody made a patch?

I spent some time checking through query strings and rewrite patterns and came up with surprisingly little. Altering filters within loader.php has little effect, and I was not able to locate any other significant functions within the includes.

As hierarchical custom content types are throwing 404’s, they seem to do so in different spots. For example, if you use the recommended /%postname%/ permalink structure, the 404 page is rendered instantly and the query string reflects this. But if you change to a custom rewrite_slug and then check the content, the query string returns not error=404 but instead attachment=my-content-slug, and a matched rewrite rule of [^/]+/([^/]+)/?$.

I’m able to work around this for the time by enabling the hierarchical flag, setting custom post parents, then disabling the flag. The content pieces retain their parent data, making it usable by the theme – the only thing that doesn’t work is the URL rewriting base.

Totally fixed it for me – thx!

Patch ready:

https://www.ads-software.com/support/topic/patch-html-character-entry-for-alternate-postpage-content

Currently debugging this – the field needs stripslashes() support, so I guess HTML was never the intended focus of this particular field.

And the answer was …?

Technically, you could install WordPress in the same directory as another CMS so long as no possible and/or recursive file name conflict exists. That said, just about every open-source system makes use of index.php.

Since the database allows prefix specification, WordPress could easily co-exist with other tables.

Do you know how to write PHP?

Thanks guys for the fast action!

Please vote for broken compatibility status on the details page to warn others about this version.

Confirmed error on upgrade to 0.9.7.7 and 0.9.7.8. Roll back to 0.9.7.6 until patch has been released!

Roll back to 0.9.7.6! Hopefully you have FTP access… I sure didn’t, had to get the server tech :S