Thanks, you are right about the mistakes and the learning, but it is also about remembering what I learned once before :-)
I will let you know here after I try them out later tonight.

Hi Ismael,

As usual thanks to you and the rest of the team for your attention and for all the hard work. Much appreciated! And thanks to all for taking a look at this.

On a related note, when testing several options,I found that these two filter generate warnings, you may also want to look at that. Neither seems to work for the backend, by the way.

// Google Maps solution after Enfold 4.5.x
// -- this disables all googlemap scripts handles frontend: avia_google_maps_front_script 
// -- and backend: avia-google-maps-api, avia_google_maps_api_script 
add_filter( ‘avf_load_google_map_api_prohibited’, ‘__return_true’ );
// This disables loading of Google ReCaptcha in the backend
add_filter( ‘avf_skip_enqueue_scripts_backend_grecaptcha’, ‘__return_true’ );

Warnings:

Warning	Use of undefined constant ‘avf_load_google_map_api_prohibited’ - assumed '‘avf_load_google_map_api_prohibited’' (this will throw an Error in a future version of PHP)

Warning	Use of undefined constant ‘avf_skip_enqueue_scripts_backend_grecaptcha’ - assumed '‘avf_skip_enqueue_scripts_backend_grecaptcha’' (this will throw an Error in a future version of PHP)

Correction:
My bad! That’s what I get as punishment for not wrapping it in a function… Embarassing…

Have a good day!
Rob

P.S.
This code from this post still seems to work however:
https://kriesi.at/support/topic/proper-method-to-disable-google-maps-in-enfold/#post-1186977

• This reply was modified 3 years ago by rob2701. Reason: Added link to code in pastebin from a post from Nikko

Hi,

To be sure of what I said, I have restored a fresh backup on the DEV website, commented out the Google Maps code in functions.php (lines 538-596) and installed Query Monitor so you can check for yourself. I have disabled compression in the theme for now.

Without that code Google Maps js is loaded in the admin area. Google ReCaptcha is also loaded in the admin area.
The options you mentioned earlier in the theme settings work fine, but only for the frontend. In the backend things are like I described here.

Login info in private window. Thanks for taking a look at this,

Rob

Hi Ismael,

Once again thank you for your patience and for the good explanation. Makes it much clearer. I learn something new every day :-)

Best regards,
Rob

Hi Rikard,

Thanks for the help, you can close it.

Rob

Hi,

Thanks so much for the modification to the avia-snippet-megamenu.js file, it works perfectly.

On a related note, what is the proper way to replace the parent theme script with the modified child theme version?
Doing it the wrong way works, and I can’t seem to find the right working way to replace it.

When I do it the wrong way, like this:

// add child theme adapted megamenu.js for keyboard accessibility of submenus
wp_dequeue_script('avia-megamenu');
wp_enqueue_script('avia-megamenu', get_stylesheet_directory_uri().'/js/avia-snippet-megamenu.js', array('avia-default'), '', true);

it works fine, but then of course I get debug notices:

Notice: wp_dequeue_script was called incorrectly. Scripts and styles should not be registered or enqueued until the wp_enqueue_scripts, admin_enqueue_scripts, or login_enqueue_scripts hooks. This notice was triggered by the avia-megamenu handle. Please see Debugging in WordPress for more information. (This message was added in version 3.3.0.) in /usr/local/www/mforams2/wp-includes/functions.php on line 5663
Notice: wp_enqueue_script was called incorrectly. Scripts and styles should not be registered or enqueued until the wp_enqueue_scripts, admin_enqueue_scripts, or login_enqueue_scripts hooks. This notice was triggered by the avia-megamenu handle. Please see Debugging in WordPress for more information. (This message was added in version 3.3.0.) in /usr/local/www/mforams2/wp-includes/functions.php on line 5663

When I (try) to do it the proper way, it does not seem to replace the parent theme one. I tried it like this:

// add child theme adapted megamenu.js for keyboard accessibility of submenus
function change_aviamegamenujs () {
    wp_dequeue_script( 'avia-megamenu' );
    wp_enqueue_script( 'avia-megamenu', get_stylesheet_directory_uri().'/js/avia-snippet-megamenu.js', array('avia-default'), '', true );
    }
add_action( 'wp_print_scripts', 'change_aviamegamenujs', 100 );

Remark: the replacement is in child theme functions.php line 687.

Can you help me do it the proper way? Thanks in advance!

Rob

• This reply was modified 3 years, 1 month ago by rob2701. Reason: location of replacement in functions.php added

Hi Yigit,

Thank you very much for the quick fix, that looks perfect now. You’re a star.

Have a good day!
Rob

Hi Ismael,

Thanks for looking into this. I replaced the code in the file like you said, but unfortunately it does not make the submenus keyboard accessible. Also, once the Enfold file compression is enabled again, it blanks the top image on home page and the images on the Tours, Impressions and Info pages, so something is not quite right yet.

I have left the replaced code in place on the dev site so you can see (also there as avia-snippet-megamenu_2021-10-04.js).
On the live website the avia-snippet-megamenu_2020-10-06.js code (also there on dev site) works well on submenus (see Blog and Info menu): https://mforamsterdam.com

Can you take another look?
Also, if you could check how I did the js replacement in child theme functions.php line 687-690, I would appreciate your advice for improvement (now gives a notice in debug log).

Thanks and have a good day,
Rob

Hi Mike,

Thanks for looking into this. I respect your conclusions, but I know what I saw on my site. Don’t worry so much about the tone, we’re all adults and can handle a little friction at times :-)
If I test with the latest theme version on a clean slate, indeed the CSS trick works on created masonry galleries like it should. But on my live site it did not (not even with div or #top specificity added). Could it be that the merge of CSS and JS played a role in the difference of behaviour before and after I saved those settings again?

Like you said, after the event it’s always difficult to assess an issue. There could indeed have many customizations in play, or even a certain version of the theme (with galleries created before the lightbox text options and lazy loading were added) behaving a certain way after the update.Btw, I used the Perfect Grid ones, don’t know if that plays a role.

I resorted to the manual fix of the galleries because I did not want the site to have the filenames below the lightbox images on all galleries. So now I have no way of going back to the original issue.

I’m sure the dev team takes great care in preparing and testing updates, and I’m always very content with Enfold. But there are just too many possible scenarios in people’s customized sites (and version update skips) for the team to cover all in advance, so that’s not a critique.

My remark about the “default action” was about the “image caption or image title if empty” and the “image description or image title if empty”. My choice would have been “or no text if empty” in those two cases.

So let’s just say I ran into an unfortunate collision of circumstances. And thanks again for looking into it.

Rob

P.S.
Guenni007, thank you also for looking into it.

Added remark:
There is an important distinction here which is of note. Normal portfolio galleries, when re-saved with the new options, do add the lightbox_text='no_text' field in the code. BUT…when a gallery has been previously added to a Blog Post (through the Insert Theme Shortcode button), before the option existed, then the only way in which this field can get added to the code later is by inserting it manually. Which is what I had to do.

• This reply was modified 3 years, 8 months ago by rob2701. Reason: Added remark about masonry galleries in blog posts

Hi Victoria,

In the meantime I have edited the masonry galleries by hand to get rid of the filenames below the lightbox images, so the link won’t do you much good, but here it is:
https://mforamsterdam.com

However, the issue is simple:
Galleries created before the option for text below the lightbox images was introduced did not have the code
lightbox_text='no_text'
of course. And since someone decided to add filenames as default when no caption was present, then all those old galleries suddenly had filenames below the lightbox images.

You can test it easily yourself by taking out the lightbox_text='no_text' from a gallery you created, then try to apply the
div .mfp-title { display: none !important;}
The only thing that works in both the default language and the translation is adding the lightbox_text='no_text' to the code.

Kind regards,
Rob

P.S.
And yes, I am also very happy that the team created the text options below the lightbox images, I just don’t understand why it needs to default to filenames instead of defaulting to “no text”…

• This reply was modified 3 years, 8 months ago by rob2701. Reason: corrected typos

Hi Ismael,

Thank you for taking a look and for the advice, very useful and helpful. It must be the tinymce option, because the plugin to toggle wpautop did not work. I (wrongly) assumed that the translation window was also Classic Editor.
You’re a star!

You can close this, thanks,
Rob