ceolmhor

I’ve posted a message in the ai1ec support forum. I’ll let you know what they say.

OK, I have good news for you, but not necessarily for me. My problem with URE is, indeed, an interaction with another plugin. I apologize for not being savvy enough to have figured this out before. I can successfully edit my Editor role into the exact set of capabilities that I want so long as I don’t have All-in-One Event Calendar by Timely (ai1ec) enabled. If I have the Editor role in the condition I prefer, and then enable ai1ec and go look at the roles using URE, the Editor role is back in its default state, rather than in the state I created using URE. I’m guessing that this means ai1ec is fouling up the role settings, but of course I’m using URE to actually see those settings, so I suppose it’s possible that the problem is an actual interaction. Ah, but I see how to test that. I’ll be right back. ??

Yes, indeed, it appears to be a simple problem with ai1ec alone. Here’s my test. With ai1ec disabled, I used URE to edit my Editor role into the configuration I want. I verified that that setting was persistent by selecting Subscriber and returning to Editor. I then deactivated URE, activated ai1ec, deactivated ai1ec, activated URE, and selected the Editor role. The role properties had then be returned to the original WordPress default values, rather than my values.

I’ll be happy to go and report this to the ai1ec folks, but I would appreciate any help others here can give me that might help me deal with the issue. For example, is there a flaw in my logic, such that these two plugins might still be interacting even though the two presumably never ran at the same time? How are such interactions usually handled? Is this a situation in which Vladimir should take any role at all (communicating with the designers of ai1ec), or should I be the only one bringing it up to them? Etc.

Knut,

This is very interesting. I added your trace output as suggested.

I chose Editor role, unchecked delete_others_pages, clicked Update and OK. Both of the trace array outputs showed delete_others_pages still set to True, but the display showed it unchecked.

I then chose Subscriber Role. At this point, both array outputs show Editor:delete_others_pages as False (i.e., no value is displayed).

I then chose Editor Role again, to see if the change persists. Both of the arrays continue to show Editor:delete_others_pages as False (no display), but the box for delete_others_pages is checked in the regular display.

Still playing, I unchecked a different field, delete_others_posts, clicked Update and OK. At this point, both trace arrays show Editor:delete_others_posts as true, and delete_others_pages as false (no display). However, the regular visual checkbox display still shows delete_others_pages as checked, and delete_others_posts as unchecked.

I chose Subscriber Role again. Both arrays now show Editor:delete_others_pages as true, and delete_others_posts as false.

I chose Editor Role again. Both arrays continue to show Editor:delete_others_pages as true, and delete_others_posts as false. However, the visual checkbox display now shows both fields as checked.

I was curious to look further at my suspicion that there’s something different about activate_plugins, a field which works correctly for me. So I checked activate_plugins, clicked Update and OK, and found that the field did not show as set in either array, but it was still set in the checkbox display.

I selected Subscriber, at which point Editor:activate_plugins was set in both arrays. I selected Editor, and found Editor:activate_plugins set in both arrays, and checked in the checkbox display.

There was a difference, however. When set, the activate_plugins field (which works correctly for me) has its value set to int(1), whereas the other two fields (which don’t work correctly for me) has the value bool(true).

Having noticed this, I looked at the array for other Editor field values that are set to int(1), instead of bool(true). I hypothesized that these fields would all work correctly for me, so that if I uncheck their values and do an update, their values will be correctly, and persistently, turned off.

I was able to perform this test for five fields (read, read_ai1ec_event, read_private_ai1ec_events, unfiltered_html, and upload_files), and they all behave correctly. I was unable to perform this test for edit_files, or all the levels (what are those, anyway?), because they were not displayed in the checkbox display.

So my belief is that all those fields whose “on” value is represented by int(1) are behaving correctly, and those whose “on” value is represented by bool(true) are not.

The new ure-lib.php didn’t fix the problem for me. I still get exactly the behavior I last reported.

I have no caching plugin in my installation.

I find no object_cache.php in my wordpress installation, which is the current version. The file, cache.php, does appear to have object_cache functionality, according to its comments, but I cannot rename or remove it, as there are require_once references to it in WordPress.

The behavior I get (can check or uncheck activate_plugins, cannot uncheck delete_others_pages, all in the Editor role) seems to be very consistent, and I would be surprised if it’s just a random timing issue.

Let me know if there’s other testing I can do for you.

OK, here’s a clue that answers a question above, and might also point out to you where a coding error might be found.

I can check or uncheck “activate_plugins” successfully, with the change retained across sessions.

I cannot successfully uncheck “delete_others_posts”, and have the change retained across sessions. This is true whether or not I also change “activate_plugins” at the same time.

I think this shows that: (1) the problem is not server-related, and (2) the problem is likely something different in the coding among different properties, that fails to set a changed flag. The changed flag doesn’t seem to be a master (global) changed flag, however, as that would be set by changing “activate_plugins”.

Vladimir: I’m hoping that this information will allow you to replicate the problem yourself, because problems go away fast when the programmer can see how to cause them. However, if you need more testing, please let me know.

As noted here:

https://shinephp.com/community/topic/edited-role-changes-dont-take

I also have this problem. Now that I know others are having the problem, I’ll try to do a bit more testing and see if I can turn up any clues to the cause.

Well, I think we’re in the same situation, but obviously you’re operating at a larger scale. My website is divided into maybe a dozen areas, so I have a dozen user accounts that are dedicated to this sort of editing.

It would also be possible to elevate individual user accounts (“Tom Jones”, for example) to Editor permissions and assign a page to that user. But I think that idea is full of headaches, so I created special accounts for each editable section (one or more pages). YMMV.

It took me some searching to find the author field. Edit a page, then look for a combobox in the upper-right corner of the screen that’s labelled “Screen Options”. Click it and check the Author box. Then you’ll be able to assign pages to individual accounts.

The plug-in I chose is called User Role Manager, but that’s not the trick you need. The way I get the specialized editing is by dividing the pages in the website into areas of responsibility (say, News Editor and Calendar Editor). I create separate roles for News Editor and Calendar Editor. These roles have the same permissions, allowing them to edit only their own pages. I then set the Author field of each page to be the editor role I want to have responsibility for that page. When, say, the News Editor logs in, she has permission to edit all the pages that were authored by the News Editor, and no others, because the defined permissions of the role allow her to edit only her own pages.

Hopefully, it’s clear that News Editor is not a role. It’s an account to which I give Editor permissions. I’ve redefined Editor permissions to allow only editing of the user’s own pages.

This isn’t perfect — it allows, for example, my To-Do plug-in to be editable by all accounts with Editor permissions. But it’s working satisfactorily, I think. It’s early days, though.

This appears to work beautifully. Thanks again, fonglh. ??

Aha. I hadn’t thought of actually altering the author of a page and setting up an editor class that can only edit “its own” stuff. I think I can see my way from here. Thanks very much, fonglh.

I understand that’s WordPress’s basic model, but was hoping for some mechanism to partition the content into groups for different editors. I take it you’re telling me that’s not something anyone has done?

I see how User Roles and Capabilities can be used to allow one user to have only read access, while another can edit. However, I don’t see how this can be used to allow one editor to edit page A, but not page B, while another editor can edit page B, but not page A, and a non-editor can see both, but edit neither. That’s my scenario. Have I missed something?

It sounds as if your database server (machine on which your database is hosted by your internet provider) is down. Do you have a method you use for directly accessing the database (e.g., phpMyAdmin, MySQL Command Center, or similar method provided by your internet hosting service)? If so, see if you can access the database that way. IAC, you should call the provider.

Rudy

Well, I’ve subsequently found Angsuman’s Authenticated WordPress Plugin, which appears to adequately protect the blog itself. It seems impossible to access content through the blog website without being logged in, and that’s part of what I want to do.

However, this plugin also prevents bona-fide users from accessing the RSS channel, since their RSS (or podcast) aggregators are not logged in. I need to be able to provide a podcast feed from this blog, but limit it to only members of the firm. I can see how I might hack the plugin to look for a constant password, and that might do for a first cut. However, it has two disadvantages: it’s passed in the clear, and it’s a single, constant password for all users. I may not be able to do any better, but thought I would ask.

I can’t imagine that we’re the first folks to encounter this situation. Can anyone help?

Rudy

I’ve been having the same trouble getting my admin page to load in IE7 Beta, but it loads fine in Firefox. Just thought I’d mention it. I haven’t tried to figure out exactly what is causing the problem, as I can get by just fine, for now, with Firefox.

Rudy