Forum Replies Created

Viewing 15 replies - 1 through 15 (of 26 total)
  • becleung

    (@becleung)

    Looks like the script type needs to be specified as “module”. Adding this might help:

    function set_scripts_type_attribute( $tag, $handle, $src ) {
    if ( 'productfilterprice' === $handle ) {
    $tag = '<script type="module" src="'. $src .'"></script>';
    }
    return $tag;
    }
    add_filter( 'script_loader_tag', 'set_scripts_type_attribute', 10, 3 );
    becleung

    (@becleung)

    It looks like the file product-filter-price.js is from a paid product, which I don’t have, so I can only guess, I can’t test my theory… but I’m guessing product-filter-price.js is being loaded too soon.

    Whatever “r” is, it’s probably defined by some script somewhere on your page, and product-filter-price.js needs to go after that.

    My script might be putting product-filter-price.js in the header when it’s supposed to be in the footer.

    So maybe you need to use wp_enqueue_script to put product-filter-price.js in the footer.

    Maybe something like this?

    add_action( 'wp_enqueue_scripts', 'enqueue_product_filter_price_after_r' );
    function enqueue_product_filter_price_after_r() {
    wp_enqueue_script('productfilterprice', plugins_url('woocommerce/assets/client/blocks/woocommerce/product-filter-price.js','woocommerce'), array(), '1.2.3', true);
    }

    You might have to adjust a few things. Such as the version number is probably not “1.2.3”, so put whatever the version number is, instead of “1.2.3”.

    • This reply was modified 6 months ago by becleung. Reason: Edited to correct mistake in wp_enqueue_script

    Just to make this thread easier to find for anyone searching for a solution to the same problem I ran into – I came across this issue on a website with the Twenty Twenty-Two theme.

    I noticed it when the hamburger menu button just seemed to stop working sporadically on an older browser (Firefox 115.19.0esr). I would click on the toggle and nothing would happen. The menu won’t open. Oddly enough, this is not an issue on an even older browser (Chrome 103.0.5060.134).

    Other websites running older WordPress themes (such as Twenty Twenty-One) had no menu issues on even these old browsers. So I thought it could be a block theme issue. But it wasn’t.

    When I was trying to figure this out, I found a lot of threads with people saying it could be a plugin conflict. It does contribute to the issue if you have a lot of plugins (the more plugins you have, the more scripts could get in front of the importmap script), but it’s not the fault of any particular plugin.

    Some web browsers have trouble getting anything from importmap if there’s a whole bunch of other javascript before this:

    <script type="importmap" id="wp-importmap">

    Those web browsers will throw an error like this:

    Uncaught TypeError: The specifier “@wordpress/interactivity” was a bare specifier, but was not remapped to anything. Relative module specifiers must start with “./”, “../” or “/”.

    In the file wp-includes/class-wp-script-modules.php, there is a public function called add_hooks()

    The trouble is, there is no priority set in the following add_action in that function:

    		add_action( $position, array( $this, 'print_import_map' ) );
    add_action( $position, array( $this, 'print_enqueued_script_modules' ) );
    add_action( $position, array( $this, 'print_script_module_preloads' ) );

    That pretty much leaves it up to chance whether the import map loads before or after other javascript.

    So to make sure it loads before most other javascript, I added this to my child theme’s functions.php file:

    remove_action( 'after_setup_theme', array( wp_script_modules(), 'add_hooks' ) );
    add_action('wp_head', 'print_import_map_before_plugin_scripts', 8);
    function print_import_map_before_plugin_scripts() {
    wp_script_modules()->print_import_map();
    wp_script_modules()->print_enqueued_script_modules();
    wp_script_modules()->print_script_module_preloads();
    echo "\r\n";
    }

    Maybe the WordPress team will add priority to those actions in the wp-includes/class-wp-script-modules.php file eventually. If that happens, it will no longer be necessary to add all this stuff to the functions.php file. But for now, this works, and it gives you just one importmap script instead of two.

    Thread Starter becleung

    (@becleung)

    Looking up aiowps_login_init led me to this support thread:

    Logged in users get redirected to profile when entering wp-login.php

    Which led me to this bit of code in another support thread:

    https://wordpress.org/support/topic/conflitto-loginpress/#post-10237326

    add_action('aiowps_wp_loaded_tasks_end', 'remove_aiowps_loaded_actions');
    function remove_aiowps_loaded_actions($AIOWPSecurity_WP_Loaded_Tasks){
    	remove_action( 'login_init', array( $AIOWPSecurity_WP_Loaded_Tasks, 'aiowps_login_init' ));
    
    }

    This does the job (without doing something as ill-advised as commenting out a line of code in AIOS). And if I want only the TML dashboard to stop redirecting, all it takes is a slight change:

    add_action('aiowps_wp_loaded_tasks_end', 'remove_aiowps_loaded_actions');
    function remove_aiowps_loaded_actions($AIOWPSecurity_WP_Loaded_Tasks){
        if(basename($_SERVER['REQUEST_URI']) === 'dashboard'){
            remove_action( 'login_init', array( $AIOWPSecurity_WP_Loaded_Tasks, 'aiowps_login_init' ));
        }
    }

    For anyone who changed that TML url to something other than ‘dashboard’, if you changed it to ‘dash’, for example – then in the above code, change ‘dashboard’ to ‘dash’ (or whatever you changed it to).

    This code can go in functions.php in your theme, or put this code in its own php file and put it in wp-content/mu-plugin

    • This reply was modified 2 years, 11 months ago by becleung. Reason: edited to add info about where to put this code

    Wow, good job figuring that out!

    I can confirm the upload path on my website is also not in the standard wp-content folder. So makbeta is very likely correct.

    Just did some updates.

    Got the same “Failed to attach a file… is not in the allowed directory” error as Celso Azevedo with v5.4.1

    Downgrading to v5.4 does fix it.

    Just coming back to report that Gutenslider 5.0.9 solves the remaining issue on older Safari browsers (with adaptive height slider showing up as a tiny bar before growing to full size on the second slide).

    This bit of css is the culprit in your case:

    /wp-content/uploads/siteground-optimizer-assets/siteground-optimizer-combined-css-a671c9eee0fbbda41fefca0298760ecd.css

    .wp-block-eedee-block-gutenslider .wp-block-eedee-block-gutenslide .wp-block-eedee-block-gutenslide {
        display: none;
    }

    Gutenslider 5.0.8 is working fine on Chrome, even on an older version like 67.0.3396.87 (Official Build) (64-bit).

    Edited to add: Siteground Optimizer is also making the arrows not clickable when it “optimizes” your site’s javascript.

    Yeah, purging your Siteground Optimizer cache might help:
    https://www.siteground.com/tutorials/wordpress/sg-optimizer/supercacher/

    I’m testing this on a WordPress install with no other plugins, using the Twenty Twenty-One theme, on Safari 12.1.2

    The slider is set to “adaptive height”

    Here is a screenshot:
    https://www.dropbox.com/s/73i0ssknkj13nfy/Screen%20Shot%202021-05-12%20at%204.37.23%20AM.png

    I realize this is a slightly older browser, so maybe a little bit of odd behavior is understandable, and it’s not worth trying to fix it if everything’s fine on newer browsers.

    The slider even shows up on Safari 9.1.3 – but with the same “starts small” behavior.

    This is a pretty minor quirk, all things considered.

    I did find another slider that scales the slideshow with the browser width while keeping the aspect ratio the same, without this quirk on older browsers, so I’m going with that. Just thought this information might be useful to you.

    Can confirm the slider is showing up in Safari now.

    Though it is doing a weird thing in Safari – it starts at a very small height – it looks like 50 pixels or so. Then it grows to full height on slide change from the first to the second slide.

    It does not behave this way on Firefox or Chrome. On those browsers it is full height right away.

    Edited to add: I figured out that small height is the padding. It helps to set “Top + Bottom” padding to zero. Still doesn’t explain why the padding height is causing this odd behavior in Safari.

    It’s not just you. I’m looking into installing a slider for a client’s new website, and this would have been my pick if not for this issue.

    I just tried Gutenslider version 5.0.6 on a completely new WordPress install with no plugins and no themes other than Twenty Twenty-One. Yes, the slideshow is blank in Safari. Works in Chrome and Firefox, though.

    Gutenslider’s own website’s header slider is blank in Safari.

    In Safari’s Web Inspector, I’m seeing this error message:

    TypeError: i[s].addEventListener is not a function. (In ‘i[s].addEventListener(“change”,n)’,’i[s].addEventListener’ is undefined)

    • This reply was modified 4 years, 10 months ago by becleung. Reason: add version number

    I’m also trying to figure out how to sync more user attributes than just First name, last name, Website URL and User Role.

    What I’ve found so far is there seems to be no way to do it right now without changing the plugin code. This code is in wp-content/plugins/mailin/page/page-home.php

    // available WordPress attributes.
    $wpAttrs = array(
    	'first_name' => __( 'First Name','sib_lang' ),
    	'last_name' => __( 'Last Name','sib_lang' ),
    	'user_url' => __( 'Website URL','sib_lang' ),
    	'roles' => __( 'User Role','sib_lang' ),
    );

    I’m going to try adding my custom user-meta to that array and see if it works. The caveat, of course, is that it’s not ideal to change the plugin code, because it’ll be wiped out whenever there’s an update.

    If there’s a better way to do it, I would like to know.

    In your theme folder, create a folder called “tribe-events”, and create a css file called “tribe-events.css” inside that folder. Then put this code inside the “tribe-events.css” file:
    .tribe-events-notices{display:none;}

    Add a css file in your theme file in a folder named tribe-events. Name the file tribe-events.css (the css in this file will override default Events Calendar css)

    This css would make them disappear:
    .tribe-events-tooltip {display: none !important;}

    This would move the boxes enough so they don’t cover the links:
    .tribe-events-calendar .tribe-events-tooltip { margin-bottom: 30px; }

    I got that from here:
    https://theeventscalendar.com/knowledgebase/stop-month-view-tooltips-from-obscuring-event-titles/

Viewing 15 replies - 1 through 15 (of 26 total)