dorsetjon

No, I haven’t had time to work through the code any further. It’s really disappointing that the developer appears to have given up supporting or developing this plugin. I’ve raised previous support questions for this and another of his plugins, both here and on his website, and never received any support. I know we’re not paying for these plugins but it would still be courteous if he would either provide some support or post an update to say no further support/updates will be provided.

OK, so it’s Condition Two that is the issue, i.e.

!agp_user_can( $type_obj->cap->edit_post, $post_id, ”, array( ‘skip_revision_allowance’ => true ) )

Now need to work out why when a post/page is first created agp_user_can() returns that the user can edit the post/page because that’s what’s stopping the notifications. Presumably this return code is wrong given that the post/page is still marked as needing approval?

Further to my last post, there are further conditions (beyond the one above that stops execution) that are not being satisfied in flt_pendingrev_post_status() such that $this->impose_pending_rev is not being populated and emails not sent. One or both of the following must be met:

Condition One

if ( ! empty( $_POST[‘rvy_save_as_pending_rev’] ) && ! empty($_POST[‘post_ID’]) )

Condition Two

if ( $type_obj = get_post_type_object( $_POST[‘post_type’] ) )
{
if ( ! agp_user_can( $type_obj->cap->edit_post, $post_id, ”, array( ‘skip_revision_allowance’ => true ) ) )

For us, Condition One is never met whereas Condition Two is only met for published pages. Condition One is not being met because $_POST[‘rvy_save_as_pending_rev’] is always empty.

I will continue working on this but there are no comments in the code so it is hard to work out what’s going on. If anyone can shed any light on this then that would be great.

This issue has existed for a long time and still exists in 1.1.12. It’s a fundamental part of Revisionary so really needs to be fixed. Looking at the code I can see why emails aren’t being sent but could do with the plugin author advising the best way to fix this. My analysis is in the following post:

https://www.ads-software.com/support/topic/email-notifications-not-sent-for-new-pages-only-revisions?replies=1

That workaround works for me. But clearly the workaround just prevents the execution of code that is presumably required so hopefully a proper fix will be provided soon.

Thanks for that. For good measure I gave full public (and group) write permissions to that directory and it didn’t help. I checked the cache report and it confirms the directory is writable. Unfortunately I’m still getting prompted for FTP credentials every time any admin page is accessed.

Do you have any other suggestions?

Found the solution:

Got to Dashboard > Events > Theme Options and click the button “reset to defaults”

That fixed it and we now get no warning notices or anything else on any screens from Adminimize.

Thanks for the very quick support!

Frank,

I also get these messages. What do you mean by “check this trunk”?

Thanks,

Jonathan

This is still broken in version 1.3.59. Is there any chance of a fix?

OK, making progress. Broadly speaking, there are 2 issues here. First, the SQL is incorrect because it includes “ALL” and “DISTINCT” (it should contain one or the other but not both) and there is no column list. That needs fixing but isn’t the cause of the TinyMCE issue.

The second issue is that in the following file there are multiple occasions when objects are treated as strings but this is not supported from PHP version 5.2:

role-scoper/hardway/cache-persistent.php

That needs changing. The particular bug that is causing the TinyMCE issue is on line 688:

$ids = array_unique($ids);

Fortunately that one is an easy fix by adding the SORT_REGULAR parameter:

$ids = array_unique($ids, SORT_REGULAR);

Making that change means TinyMCE is now available again. An alternative workaround for those that don’t want to edit code is to turn off Role Scoper caching by unticking the checkbox in:

Roles->Options->Features->Internal Cache

Hopefully this will be fixed in the next version of Role Scoper because it breaks functionality for anyone using PHP 5.2 or higher.

Further investigation shows that when this issue occurs the TinyMCE Javascript is missing from the page and indeed is some other standard HTML, so it looks like an exception is occurring in Revisionary or Role Scoper that is interrupting the creation of the page. I have put WordPress in debug mode and found that the following errors are associated with this issue:

WordPress database error: [Incorrect usage of ALL and DISTINCT]
SELECT DISTINCT all FROM wp_users INNER JOIN wp_user2role2object_rs AS uro ON uro.user_id = wp_users.ID WHERE 1=1 AND uro.user_id > 0 AND ( ( ( ( ( ( ( uro.scope = ‘object’ AND uro.assign_for IN (‘entity’, ‘both’) AND uro.src_or_tx_name = ‘post’ AND uro.role_type = ‘rs’ AND uro.role_name IN (‘page_editor’,’editor’,’administrator’) AND uro.obj_or_term_id = ‘434’ ) ) OR ( ( uro.scope = ‘blog’ AND uro.role_type = ‘rs’ AND uro.role_name IN (‘page_editor’) ) OR ( uro.scope = ‘blog’ AND uro.role_type = ‘wp’ AND uro.role_name IN (‘editor’,’administrator’) ) ) ) ) OR ( ( ( ( uro.scope = ‘object’ AND uro.assign_for IN (‘entity’, ‘both’) AND uro.src_or_tx_name = ‘post’ AND uro.role_type = ‘rs’ AND uro.role_name IN (‘page_author’) AND uro.obj_or_term_id = ‘434’ ) ) OR ( ( uro.scope = ‘blog’ AND uro.role_type = ‘rs’ AND uro.role_name IN (‘page_author’) ) OR ( uro.scope = ‘blog’ AND uro.role_type = ‘wp’ AND uro.role_name IN (‘administrator’) ) ) AND uro.user_id = ’37’ ) ) ) ) )

Warning: Illegal offset type in isset or empty in /var/www/vhosts/swallowboatsassociation.com/httpdocs/dev/wordpress/wp-content/plugins/role-scoper/hardway/cache-persistent.php on line 422

Warning: hash_hmac() expects parameter 2 to be string, object given in /var/www/vhosts/swallowboatsassociation.com/httpdocs/dev/wordpress/wp-content/plugins/role-scoper/hardway/cache-persistent.php on line 478

Warning: Illegal offset type in /var/www/vhosts/swallowboatsassociation.com/httpdocs/dev/wordpress/wp-content/plugins/role-scoper/hardway/cache-persistent.php on line 447

Warning: Illegal offset type in /var/www/vhosts/swallowboatsassociation.com/httpdocs/dev/wordpress/wp-content/plugins/role-scoper/hardway/cache-persistent.php on line 624

Warning: Illegal offset type in isset or empty in /var/www/vhosts/swallowboatsassociation.com/httpdocs/dev/wordpress/wp-content/plugins/role-scoper/hardway/cache-persistent.php on line 626

Catchable fatal error: Object of class stdClass could not be converted to string in /var/www/vhosts/swallowboatsassociation.com/httpdocs/dev/wordpress/wp-content/plugins/role-scoper/hardway/cache-persistent.php on line 688

Catchable fatal error: Object of class stdClass could not be converted to string in /var/www/vhosts/swallowboatsassociation.com/httpdocs/dev/wordpress/wp-content/plugins/role-scoper/hardway/cache-persistent.php on line 688

Stina,

I have been experimenting with something similar and couldn’t find any standard way to do this but it can be done with a small customization. To add a link under each thumbnail in the gallery view, edit the following file:

wp-content/plugins/nextgen-gallery/view/gallery.php

On or near line 47 there is following:

<span"><?php echo $image->caption ?></span>

I added the following line immediately after the <span> line:

<a href="<?php echo $image->imageURL . "_backup" ?>" title="<?php echo $image->description ?>" target="_blank" >Open full size image</a>

This adds a link below each thumbnail and clicking on the link will open the full size version of the image in a new window. Note that the code doesn’t check whether a full size version exists.

If anyone’s interested, another approach (and this is what I wanted) is to be able to open the original full size image when you click on the normal (resized) image while viewing that. I use the shutter viewer so customized that. Edit this file:

wp-content/plugins/nextgen-gallery/shutter/shutter-reloaded.js

We need to change the click action to open the full size image rather than closing the image viewer. We therefore also need a new way to close the viewer, so for that I add an ‘X’ to the bottom right of the view and clicking that closes the window.

On around line 135 add the following to create a variable holding the code for the new close link:

var closelink='<a style="font-family: Arial, Sans-serif; margin: 0px;" href="#" id="shClose" title="Close" onclick="shutterReloaded.hideShutter();">x</a>';

Immediately after that are lines that populate NavBar and D.innerHTML. Comment out the originals of those lines and insert the following:

NavBar = '<div id="shTitle"><div id="shPrev">' + prevlink + '</div><div id="shNext">' + nextlink + closelink + '</div><div id="shName">' + shutterLinks[ln].title + '</div>' + imgNum + '</div>';

D.innerHTML = '<div id="shWrap"><img src="'+shutterLinks[ln].link+'" id="shTopImg" title="Click for full size image" onload="shutterReloaded.showImg();" onclick="' + "var http = new XMLHttpRequest(); http.open('HEAD', this.src+'_backup', false); http.send(); if (http.status!=404) window.open(this.src+'_backup'); else alert('No full size image available');" + '" />' + NavBar +'</div>';

The NavBar line is updated to include a new close link and the D.innerHTML update causes the full size image to open when the normal image is clicked. Before opening the full size image it checks to see if one exists (using XMLHttpRequest) and an error message is displayed if none is available.

No doubt there are other and probably better ways to do this but this approach worked for me.

We fixed this by editing the file plugins/revisionary/admin/admin_rvy.php and changing the following line:

if ( $admin_notify && ! empty($post_arr[‘prev_cc_user’]) ) {

to become:

if ( $admin_notify ) {

Thanks, that works!