I turned on debugging. It logs a lot more actions when the admin does it than when an editor does it, however the debugging seems to suggest that it is trying to delete the cache when the edit makes a change, and I can’t figure out where it’s doing permission checks in the code.
I’m seeing some funny business in the supercache dir output … that includes both path AND a URL to a revision of the post, rather than the permalink to it (I put in {removed} to hide actual paths):
18:48:12 /wp-admin/post.php Clearing cache for post 14239 on post edit.
18:48:12 /wp-admin/post.php supercache dir: {removed}/wp-content/cache/supercache/tunxis.eduhttp:/tunxis.edu/93-revision-4/&post_type=revision&preview=1/
I think that should look like
18:48:12 /wp-admin/post.php Clearing cache for post 14239 on post edit.
18:48:12 /wp-admin/post.php supercache dir: {removed}/wp-content/cache/supercache/tunxis.edu/college-information/graduation/faq/
Other potentially helpful bits of info:
- edit url is https://tunxis.edu/wp-admin/post.php?post=93&action=edit
- i notice that the
get_current_url_supercache_dir function has some logic so that if no post_id is passed in, it runs $uri = strtolower( $wp_cache_request_uri ); … this WOULD be happening in this case because wp_cache_post_change is running this code: `if( $super_cache_enabled ) {
$dir = get_supercache_dir();`
I feel like that last part is wrong. I feel like $post_id should get passed to get_current_url_supercache_dir because it IS known at the time the code is run in wp_cache_post_change. I’m going to see what happens if I pass $post_id.
I just noticed that a little while later in the log, I do have some entries that look more promising but still don’t hit the mark:
{removed}/wp-content/cache/supercache/tunxis.eduhttp:/tunxis.edu/college-information/graduation/faq/
This sucks. I’m trying to switch checks from using wp_supercache_admin() to using 2 custom capabilities I created, but unfortunately, everything currently routes through options-general.php, including the action to delete the page cache, which means you always need manage_options capability, so I wind up with ‘You do not have sufficient permissions to access this page’ if the user is an editor.
I don’t know a lot about plugin development and routing shit through different files so the built-in permission checks don’t fire, and I don’t know if I should be trying to circumvent it, but I have a feeling I’m going to learn.
Seems to me that deleting the page cache should be one capability check on top of the edit_post capability. So maybe the page cache delete thing should be hooked onto edit page/post.
idk.
goddammit.
Hi, can you try the development version as it fixed a number of bugs in 1.0?
http://downloads.wordpress.org/plugin/wp-super-cache.zip
I’ll hopefully get a chance to look at this over the weekend.
Donncha
Editor still cannot update the cached version of a page.
I’ve created a replacement of wp-cache.php. This is a modification to the dev version, so it should be fairly easy to merge into the development branch. http://pastebin.com/gBznjQZk
This version replaces using wpsupercache_site_admin() with checks for capabilities on the current user/role. I added 2 capabilities: wpsupercache_manage_options and wpsupercache_delete_page_cache. I assign both capabilities to roles with manage_options caps and wpsupercache_delete_page_cache to roles with edit_pages caps. One could install the Capability Manager plugin to modify the default permissions. Capabilities are added upon activation and removed upon deactivation.
Let me know if you need further explanation of anything.
This probably breaks compatibility with older version of wordpress because I assume the existence of the current_user_can function.
