Paul Menard

@muuta,

Just tested on a clean WP 3.9 install with default theme and no other plugins running. Not seeing that warning.

What options within the Simply-Exclude are you selecting/enabling?

@harrisr7,

Yeah, this is similar to the other thread https://www.ads-software.com/support/topic/get_attachments_by_media_tags-in-version-12?replies=8

I have a bug on the logic where the args are not being parsed.

You can try the beta I posted this morning. Or wait until the version is released later today.

https://dl.dropboxusercontent.com/u/2616987/projects/wp-plugins/media-tags/media-tags-3.2.0.1-Beta1.zip

@bev,

Thanks for the code suggestion. I think it is better and cleaner to move the wp_parse_args logic form the two secondary function and only need to large the args once.

Here is a beta with the patched code. Thanks

https://dl.dropboxusercontent.com/u/2616987/projects/wp-plugins/media-tags/media-tags-3.2.0.1-Beta1.zip

@bev,

Oh I guess you are correct. My fault. Will have this patched later today. Thanks.

@bev,

Not exactly. The function get_attachments_by_media_tags() (media_tags.php line 134) is really just an intermediate function. Depending on the query type setting that function will then call either get_attachments_by_media_tags_query() or get_attachments_by_media_tags_legacy(). Within those secondary function is where wp_parse_arge() is called.

From media_tags.php lines 161-165

if ((strtolower($args['query']) == 'wp_query')) {
	return $this->get_attachments_by_media_tags_query($args);
} else if ((strtolower($args['query']) == 'legacy')) {
	return $this->get_attachments_by_media_tags_legacy($args);
}

The query type defaults to ‘wp_query’ which is the new logic. As I asked from my previous post you can use the legacy query type by adding the following to your wp-config.php

define(‘MEDIA_TAGS_QUERY’, ‘legacy’);

@bev,

Hmm. There was a major change to how the query was made. In prior version it was using older style queries. In 3.2 the queries are called via WP_Query for efficiency.

A couple of options.

1. Revert back to 3.1.2.1 and go along your way. I personally don’t want that. I want to see if this is just your issue or related to the changes

2. Try settings the following define in your wp-config.php. This will allow Media-Tags to used the old legacy query method. If this works then we need to discuss the exact use of the Media-Tags plugin within your system so I can figure out how to replicate your issue.

Add this to your wp-config.php

define(‘MEDIA_TAGS_QUERY’, ‘legacy’);

@flymike,

I can’t explain this – but I would like to leave the old version key deleted. Is there any dependency on it in 2.0.6.1?

No. When 2.0 came out is when I added the ‘simplyexclude_v2’. You are seeing the older version ‘simplyexclude’ because you were probably running a version prior to 2.0. Thanks for that.

@flymike,

I can’t address what you are doing with the backups, etc.

The Simply Exclude stores the settings into the WordPress options table. The option_name for the row is ‘simplyexclude_v2’.

@dking64,

Fixed in new Beta6. Though I could not decided to fixe it or remove it. Since the tab is the Role. It was just a hiccup on the role name output. Nothing at all to do with custom roles or such.

https://dl.dropboxusercontent.com/u/2616987/projects/wp-plugins/media-tags/media-tags-3.2-Beta6.zip

New Media-Tags 3.2 Beta 4

https://dl.dropboxusercontent.com/u/2616987/projects/wp-plugins/media-tags/media-tags-3.2-Beta4.zip

Corrected issues on mediatags_settings.php when user role is empty. Also correct loading asset URLs when under SSL. Thanks @i_leo on both issues.

@dking64,

I’m not sure I can reproduce the issue you reported. Then again on my own development site the number of users is 1-3 in each role group. I’m not seeing any issue when switching roles. Can you provide more details? Will be glad to look into further.

@i_leo,

Thanks for the feedback. Will look into the issues.

@dking64,

Thanks for the details. As I mentioned there is nothing in the WP infrastructure to support this. The Media-Tags roles management was just a nice screen so that I didn’t have to tell the admin to install a second roles management plugin to add/delete role capabilities. But again this is by role not specific to any taxonomy item.

The WordPress core is supposed to be working on taxonomy meta storage. When that comes (not sure when) then will have some ability to store logic per the individual tags. https://make.www.ads-software.com/core/2013/07/28/potential-roadmap-for-taxonomy-meta-and-post-relationships/

@dking64,

Great. Thanks for reviewing the beta.

Is there a way to extend roles management so certain roles have or don’t have access to items with particular media tags?

Not that I’m aware of. So are you caking for restriction from the edit of the tag or viewing on the frontend?

As far as I know this would need to be provided as part of WP core. Media-Tag tags are really just a taxonomy like post tags. So any extra functionality like that would ned to already exist as part of the taxonomy logic. Follow?

@dpnserver,

I spent the afternoon trying to debug the issue you reported with Snapshot and this Anti CSRF plugins. Like your posts to this thread when I try to save any part of Snapshot even something in Snapshots > Settings, which are all simple post forms, I get the generic error screen from Anti CSRF.

So being a plugin developer myself I went a little deeper into the Anti CSRF plugin code. Can’t say I like the way this plugin works. Where to start. Hopefully the plugin developer can read this and not just ignore the post.

1. The logic for validating the ‘bawac_force_nonce’ is not correct. See line 49 of the plugin:
if( count( $_REQUEST ) && ( !isset( $_REQUEST['bawac_force_nonce'] ) || !wp_verify_nonce( $_REQUEST['bawac_force_nonce'], '__BAW__' ) ) )
The problem is not the verify but that you are checking the _REQUEST super global. The root of the issue is that you are setting both a $_POST and $_GET ‘bawac_force_nonce’ instance. And get this they have different values. See next points.

2. I noticed in the admin ‘bawac_force_nonce_init’ function at line 57 you start caching the content. In the footer function ‘bawac_force_nonce_foot’ at line 89 you then call ‘ob_get_contents’ to get all the cached page content. Sorry but this is just wrong. You may think setting the priority to 999 will mean your footer function is called last but it is not a guarantee. I can setup a footer function with priority or 10000 and then add some malicious links and JS.

3. Creating duplication of ‘bawac_force_nonce’ form variable. And they have two different values. As I mentioned in point #1 you are crestings both a _POST and _GET variable ‘bawac_force_nonce’. At line 91 you have the following code

wp_nonce_field( '__BAW__' . date( 'a' ), 'bawac_force_nonce', false, false )

Notice the date(‘a’) element. Not sure why this is even here. why would you think you need to add a unique element to a function which in itself produces unique output. As a result in the actual form you end up with two different values

<form method="post" action="?bawac_force_nonce=9b4df144f1&page=snapshots_settings_panel">
<input id="bawac_force_nonce" type="hidden" value="1bac9b78dc" name="bawac_force_nonce">
<input type="hidden" value="snapshots_settings_panel" name="page">

As I mentioned in point #1 you are checking only _REQUEST. Since this then depends on the php.ini settings for ‘variables_order’ ‘https://us3.php.net/manual/en/ini.core.php#ini.variables-order you don’t have control of if _REQUEST is taken from _GET or _POST. IT may work on one PHP setup but not another.

A proper solution would be to check the _SERVER[‘REQUEST_METHOD’] then check the appropriate ‘bawac_force_nonce’ global. Then use that to test in your if statement.

if ($_SERVER[‘REQUEST_METHOD’] == “POST”) {
$verify_ret = wp_verify_nonce( $_POST[‘bawac_force_nonce’], ‘__BAW__’ . date( ‘a’ ) );
} else {
$verify_ret = wp_verify_nonce( $_GET[‘bawac_force_nonce’], ‘__BAW__’ );
}
if(count( $_REQUEST ) && ( !isset( $_REQUEST[‘bawac_force_nonce’] ) || !$verify_ret ) )

Also I don’t really see the point of checking the count of _REQUEST items. who cares. So if it is empty this is cause for an error? Not logical.

4. And last point back to your footer. At line 91 you are not only adding your own nonce var which I understand. But why do you think it valid to add the ‘page’ reference? Again this override (potentially) the page var in the form action URL which is the important one. From what I can tell you logic is not effecting or changing the page value which is great. But again it causes duplicate global vars. You don’t own the page the plugin who create the page does. It has rights to the ‘page’ element in the forms not your plugin.

If you are feeling adventurous you might want to yes the latest beta. The beta is really a rewrite of the core query logic to use the modern WP_Query instead of get_posts multiple times. Plus added some cleanup to the roles system.

https://dl.dropboxusercontent.com/u/2616987/projects/wp-plugins/media-tags/media-tags-3.2-Beta1.zip