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

PMPRO is aggressively loading its own version of select2 on ALL admin pages #2902

Open
1 of 3 tasks
zagarskas opened this issue Mar 23, 2024 · 3 comments
Open
1 of 3 tasks

Comments

@zagarskas
Copy link

zagarskas commented Mar 23, 2024

Describe the bug
Very simple: PMPRO is aggressively loading its own version of select2 on ALL admin pages.

This creates problems. There are other plugins and themes out there using PRE 4.0 select2, and the newest select2 4.1.1 - a conflict then ensues.

To Reproduce
Steps to reproduce the behavior:

  1. install PMPRO
  2. write custom code for your own theme or plugin that uses another version of select2
  3. watch the PMPRO version of select2 load into the page and cause issues

Screenshots
src="/wp-content/plugins/paid-memberships-pro/js/pmpro-admin.js"
image

Expected behavior
this ambiguous handle: "select2-js" would better be "pmpro_admin-select2-js" so we can identify and dequeue it.
Also ideal: not loading PMPRO's version of select2 on every wp-admin page would be courteous

consider that some of us are using this:
Select2 4.1.1-rc.2 | https://github.com/select2/select2/blob/master/LICENSE.md
and have modified the core to patch this issue -- Added non-passive event listener to a scroll-blocking event.
angular/components#4221

Isolating the problem (mark completed items with an [x]):

  • I have deactivated other plugins and confirmed this bug occurs when only Paid Memberships Pro plugin is active.
    meh... not really. because that would make the "bug" disappear

  • This bug happens with a default WordPress theme active, or Memberlite.
    meh... not a fair request in this case

  • I can reproduce this bug consistently using the steps above.

WordPress Environment

``` n/a ```
@zagarskas
Copy link
Author

zagarskas commented Mar 23, 2024

Digging into this some more, check out this nicely restricted usage:
plugins\paid-memberships-pro\includes\scripts.php

    // Enqueue select2 on front end and user profiles
	if( pmpro_is_checkout() || 
        ! empty( $_REQUEST['level'] ) ||
        ! empty( $pmpro_level ) ||
		( class_exists("Theme_My_Login") && method_exists('Theme_My_Login', 'is_tml_page') && Theme_My_Login::is_tml_page("profile") ) ||
		( isset( $pmpro_pages['member_profile_edit'] ) && is_page( $pmpro_pages['member_profile_edit'] ) ) ) {
		wp_enqueue_style( 'select2', plugins_url('css/select2.min.css', dirname(__FILE__)), '', '4.0.3', 'screen' );
		wp_enqueue_script( 'select2', plugins_url('js/select2.min.js', dirname(__FILE__)), array( 'jquery' ), '4.0.3' );
	}

Its good that member_profile_edit and member_profile_edit are limited.

But on the back end Forcing select2 into all admin pages is too aggressive. For example:

See: pmpro_admin_enqueue_scripts()

add_action( 'admin_enqueue_scripts', 'pmpro_admin_enqueue_scripts' );

/**
 * Enqueue admin JavaScript and CSS
 */
function pmpro_admin_enqueue_scripts() {
    // Enqueue Select2.  
    wp_register_script( 'select2',
                        plugins_url( 'js/select2.min.js', dirname(__FILE__) ),
                        array( 'jquery', 'jquery-ui-sortable' ),
                        '4.0.3' );
    wp_enqueue_style( 'select2', plugins_url('css/select2.min.css', dirname(__FILE__)), '', '4.0.3', 'screen' );
    wp_enqueue_script( 'select2' );

There is no consideration at all here for loading select2 only onto PMPRO pages.

I would propose the use of $screen = get_current_screen(); to at least determine the core PMPRO pages, and then considerately load select2 [only there, where it belongs, in PMPRO admin pages]

@zagarskas
Copy link
Author

zagarskas commented Mar 23, 2024

Currently, here is the patch I am using

   add_action( 'admin_enqueue_scripts', array( $this, 'select2_fixes' ), 100 );
            public function select2_fixes() {
				if(class_exists("PMPro_Field")) {
					$screen = get_current_screen();
					if (!str_contains($screen->id, 'pmpro')) { 
						  wp_deregister_script( 'select2' );
						  wp_dequeue_script( 'select2' );
						  wp_deregister_style( 'select2' );
						  wp_dequeue_style( 'select2' );
					}
				}
            }

which seems legit for now (to stop client-yelling :( )... but, what if I am removing select2 when its needed?

I think it would be wonderful if something like this was tacked on here:
here: \plugins\paid-memberships-pro\includes\scripts.php
more specifically: add_action( 'admin_enqueue_scripts', 'pmpro_admin_enqueue_scripts' );
Lines 104-113

/** 
 * Enqueue admin JavaScript and CSS
 * What if you only did this when its a PMPro screen?
 */
function pmpro_admin_enqueue_scripts() {
    // Enqueue Select2.  - but... only where it belongs

	$screen = get_current_screen(); // seems like all pmpro screen say so...
	if (str_contains($screen->id, 'pmpro')) {  //which is nice...
		wp_register_script( 'pmpro_admin-select2', plugins_url( 'js/select2.min.js', dirname(__FILE__) ), array( 'jquery', 'jquery-ui-sortable' ), '4.0.3' );
		wp_enqueue_style( 'pmpro_admin-select2', plugins_url('css/select2.min.css', dirname(__FILE__)), '', '4.0.3', 'screen' );
		wp_enqueue_script( 'pmpro_admin-select2' );
	}

or... tack on a dependency for wp_register_script( 'pmpro_admin', might be a great quick idea!

@creador-dev
Copy link

creador-dev commented Jul 19, 2024

Same issue here. Please resolve it. Why do you guys need to load scripts on every page is there any reason?

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