Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[>3.8.2] Plugin administration not working anymore - WPML conflict #153

Closed
tlebars opened this issue Jul 10, 2024 · 10 comments
Closed

[>3.8.2] Plugin administration not working anymore - WPML conflict #153

tlebars opened this issue Jul 10, 2024 · 10 comments

Comments

@tlebars
Copy link

tlebars commented Jul 10, 2024

Hello,

Since plugin version 3.8.3(3.8.4 and 3.8.5 have the issue too), the authorizer administration dashboard no longer seems to work.

No matter where you click (on one of the tabs, for example), the browser returns the following error:

VM1420:1 Uncaught ReferenceError: chooseTab is not defined

or :

Uncaught ReferenceError: authAddUser is not defined at HTMLAnchorElement.onclick (options-general.php?page=authorizer&paged=24:1162:184)`

The extension works with the settings already in place, but no further user updates are possible.

Furthermore, when looking in the browser's devtool, no JS files seem to be loaded :

authorized_issue

Any idea where the problem might be coming from?

Thanks

@tlebars tlebars changed the title [3.8.5] Plugin administration not working anymore - Javascript issue [>3.8.2] Plugin administration not working anymore - Javascript issue Jul 10, 2024
@figureone
Copy link
Member

Hm, you seem to be missing the admin javascript, the sources should look like this on the admin dashboard:
Screenshot 2024-07-10 at 10 56 18 AM

We confirmed it's present in the wordpress.org plugin repo and the github repo (we sync github to wordpress.org svn whenever we deploy a new version):
https://plugins.svn.wordpress.org/authorizer/tags/3.8.5/js/
https://github.com/uhm-coe/authorizer/tree/master/js

Maybe a botched upgrade? Can you try reinstalling the plugin from the zip file?
https://downloads.wordpress.org/plugin/authorizer.3.8.5.zip

@figureone
Copy link
Member

figureone commented Jul 10, 2024

One other possibility if you do see authorizer.js file present in the plugin source: jquery-effects-shake is a javascript dependency, so if that script is missing or unregistered, it won't load:
https://github.com/uhm-coe/authorizer/blob/master/src/authorizer/class-admin-page.php#L1162

jquery-effects-shake is still listed as a core registered script, so check to see if your theme or other plugins might be unregistering it:
https://developer.wordpress.org/reference/functions/wp_register_script/#core-registered-scripts

@tlebars
Copy link
Author

tlebars commented Aug 7, 2024

Hi,

A brief update on the problem. There seems to be an incompatibility with the WPML plugin :

2024/08/07 09:04:10 [error] 1021344#1021344: *52627 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught ArgumentCountError: Too few arguments to function SitePress::terms_clauses(), 1 passed in [...]/wp-includes/class-wp-hook.php on line 326 and exactly 3 expected in [...]/wp-content/plugins/sitepress-multilingual-cms/sitepress.class.php:2648
Stack trace:
#0 [...]/wp-includes/class-wp-hook.php(326): SitePress->terms_clauses()
#1 [...]/wp-includes/plugin.php(205): WP_Hook->apply_filters()
#2 [...]/wp-includes/class-wp-term-query.php(734): apply_filters()
#3 [...]/wp-includes/class-wp-term-query.php(311): WP_Term_Query->get_terms()
#4 [...]/wp-includes/taxonomy.php(1357): WP_Term_Query->query()
#5 [...]/wp-includes/taxonomy.php(2316): get_terms()
#6 [...]/wp-includes/taxonomy.php(3832): wp_get_object_terms()
#7 [...]/wp-includ" while reading upstream, client: [...], server: [...], request: "GET [...]/wp-admin/options-general.php?page=authorizer HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.1-fpm.sock:", host: "[...]", referrer: "[...]/wp-admin/plugins.php"

The functions get_terms_args_filter and terms_clauses in [...]/wp-content/plugins/sitepress-multilingual-cms/sitepress.class.php require respectively 2 and 3 arguments which are not provided when using Authorizer.

By replacing :

  • function get_terms_args_filter( $args, $taxonomies ) {[...]

with :

  • function get_terms_args_filter( $args=[], $taxonomies=[]) {[...]

and replacing :

  • function terms_clauses( $clauses, $taxonomies, $args ) {[...]

with :

  • function terms_clauses( $clauses, $taxonomies=[], $args=[] ) {[...]

the latest versions (>3.8.2) of Authorizer are working properly again.

@figureone
Copy link
Member

We had a workaround for this where we temporarily removed the terms_clauses hook that WPML creates: https://github.com/uhm-coe/authorizer/blob/master/src/authorizer/options/class-public-access.php#L196-L204

Since we don't have access to the latest WPML source, can you check and see if they changed how they register their hook? If so we can update our codebase to try to match.

Alternatively, your solution for modifying WPML also works, if you want to try to submit that to the WPML maintainers.

@tlebars
Copy link
Author

tlebars commented Sep 3, 2024

Hey,

Looking at your workaround, I don't quite understand why in the if loop, there is both the line : remove_filter( 'terms_clauses', array( $GLOBALS['sitepress'], 'terms_clauses' ) ); and the line : add_filter( 'terms_clauses', array( $GLOBALS['sitepress'], 'terms_clauses' ) );.

By removing this one : add_filter( 'terms_clauses', array( $GLOBALS['sitepress'], 'terms_clauses' ) );, WPML is working fine with Authorizer. Could this be the solution?

Moreover, I don't really understand why the line : $categories = get_categories( array( 'hide_empty' => false ) ); is in both the if and else statements ?

@tlebars tlebars changed the title [>3.8.2] Plugin administration not working anymore - Javascript issue [>3.8.2] Plugin administration not working anymore - WPML conflict Sep 3, 2024
@figureone
Copy link
Member

Can you try commenting out both the remove_filter() and add_filter() lines? It's possible that WPML rewrote how they hooked into terms_clauses, and our code no longer matches their codebase. (We don't have access to their code since it is no longer open source.)

Regarding why those lines exist, we basically remove the custom WPML filter before we query get_categories(), because that's where the terms_clauses hook fires. In previous versions of WPML, that caused problems with the returned categories. After we fetch the categories, we call add_filter() to restore the WPML hook (just to restore the state to how it was before we removed their filter).

@tlebars
Copy link
Author

tlebars commented Sep 5, 2024

Thanks for the explanation.

I confirm that by commenting out the complete code block, everything works correctly.

@figureone
Copy link
Member

We can't remove the entire code block because Authorizer needs to fetch the categories with get_categories().
Can you try just commenting lines 199 (the remove_filter()) and 201 (the add_filter()) to see if WPML fixed the bug that made us tweak that hook?
https://github.com/uhm-coe/authorizer/blob/master/src/authorizer/options/class-public-access.php#L199
https://github.com/uhm-coe/authorizer/blob/master/src/authorizer/options/class-public-access.php#L201

@tlebars
Copy link
Author

tlebars commented Sep 6, 2024

Hello,

I can confirm that by commenting on these two lines of code alone, everything works just as well.

@figureone
Copy link
Member

OK great! You can leave them commented out on your setup; we'll remove that extra check in the next release of Authorizer so it should continue working after you upgrade.

figureone added a commit that referenced this issue Sep 6, 2024
Introduced in #25; @tlebars confirmed fix no longer necessary in #153
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants