ppwebox

Thanks for the clarification. But why omit that it is Complianz that is actually loading Google Maps on ever page (this site only really uses it on one singe page)?

Proof is in the html source code of every page:

<script  type="text/plain" data-service="google-maps" data-category="statistics"  data-cmplz-src="https://maps.googleapis.com/maps/api/js?libraries=places&amp;key=AIzaSyAI2EabN_2uN0AzVPflalJuBuJ6Yn8aAyE&amp;language=de&amp;region=DE&amp;ver=7.4.0.1703811086" id="googlemap-js"></script>

So again: how can this senseless GMaps loading be circumvented and only load when it is actually called by the Modern Events Calendar plugin on the specific page? Complianz is seriously affecting page speed performance here!

Hi Jarno

While analyzing a client site (with Modern Events Calendar installed) for page load improvement I noticed that your script is loading Google Maps on every page which is bad for performance!

Would it be possible to modify the script to only load Google Maps on shop pages where the URL slug contains “/events/”? I tried the check in the cmplz_known_script_tags filter but Maps is still loading.

function cmplz_webnus_modern_events_googlemaps_script( $tags ) {
$tags[] = array(
‘name’ => ‘google-maps’,
‘placeholder’ => ‘google-maps’,
‘category’ => ‘statistics’,
‘urls’ => array(
‘richmarker’,
‘maps.googleapis.com/maps/api/js’,
‘googlemap.js’,
‘function mec_init_gmap’,
‘mecGoogleMaps’,
),
‘enable_placeholder’ => ‘1’,
‘placeholder_class’ => ‘mec-googlemap-details’,
‘enable_dependency’ => ‘1’,
‘dependency’ => [
//’wait-for-this-script’ => ‘script-that-should-wait’
‘maps.googleapis.com/maps/api/js’ => ‘googlemap.js’,
‘googlemap.js’ => ‘richmarker’,
‘richmarker’ => ‘function mec_init_gmap’,
‘richmarker’ => ‘mecGoogleMaps’,
],
);
return $tags;
}
add_filter( ‘cmplz_known_script_tags’, ‘cmplz_webnus_modern_events_googlemaps_script’ );

• Add services to the list of detected items, so it will get set as default, and will be added to the notice about it
• @param $services
• @return array
  */
  function cmplz_webnus_detected_services( $services ) {
  global $wp;
  $url_slug = add_query_arg( array(), $wp->request );
  $url_slug = ‘/’ . $url_slug;
  if ( strpos($url_slug, ‘/events/’) !== false && ! in_array( ‘google-maps’, $services ) ) {
  $services[] = ‘google-maps’;
  } return $services;
  }
  add_filter( ‘cmplz_detected_services’, ‘cmplz_webnus_detected_services’ );

Same error here, but “Calendar Event Multi View” is not installed. Instead Modern Events Calendar and its addons are running. However, no other plugin ever caused such an error as Tablepress, so there is certainly a dependency in your code which is fatally buggy.

Log entry:

Ein Fehler vom Typ E_ERROR wurde in der Zeile 301 der Datei /wp-content/plugins/tablepress/models/model-options.php verursacht. Fehlermeldung: Uncaught TypeError: TablePress_Options_Model::map_tablepress_meta_caps(): Argument #2 ($cap) must be of type string, null given, called in /wp-includes/class-wp-hook.php on line 310 and defined in /wp-content/plugins/tablepress/models/model-options.php:301
Stack trace: 0 /wp-includes/class-wp-hook.php(310): TablePress_Options_Model->map_tablepress_meta_caps() 1 /wp-includes/plugin.php(205): WP_Hook->apply_filters() 2 /wp-includes/capabilities.php(842): apply_filters() 3 /wp-includes/class-wp-user.php(777): map_meta_cap() 4 /wp-includes/capabilities.php(985): WP_User->has_cap() 5 /wp-includes/capabilities.php(877): user_can() 6 /wp-admin/menu-header.php(202): current_user_can() 7 /wp-admin/menu-header.php(298): _wp_menu_output() 8 /wp-admin/admin-header.php(258): require(‘/home/wwwcustom…’) 9 /wp-admin/index.php(137): require_once(‘/home/wwwcustom…’) 10 {main}

thrown

Thanks Jarno, this script works perfectly with Webnus MEC as far as I can see.

Experiencing the same bug as reported in the initial thread. As to your observation that disabling Elementor’s flexbox container mode solves the mini cart issue, this is not true on my end.

Just tested it with an older ELMT pro version: disable in Experiments, open and re-save header template, regenerate ELMT CSS & Data, flush WP cache, flush browser cache, reload product page and add to cart – mini cart still displays a blank page.

This must be a Woocommerce bug exclusively since the local version of my site has much newer version of ELMT Pro but both have the same newest Woo version.

Got the same mini cart bug with Elementor and Woo. All at their latest version. The cart sidebar does work when in the theme customizer, as others have mentioned. The bug appears on two sites with very different Elementor/Pro versions (3.7.7 vs 3.13.1), only the Woocommerce version is at the latest 7.8.0 version. So Woocommerce must be the culprit.

Tried all suggestions found when googling Woo mini cart problem, including deactivating all other plugins and changing the theme, but nothing has fixed this critical usability bug. But even downgrading Woo to version 7.0.0, clearing cache and repairing/updating the database has been futile.

Never auto-update anything from MEC! Their code testing is abysmal. Really poor. Thus almost any update will introduce new bugs while older ones which were reported by users may have been fixed if your patient. This is my experience with MEC Pro and the Elementor add-ons. Been burned once by Webnus on a client site hence always test updates first locally before updating live.

Well of course I’m using local fonts for performance and compliance reasons.

It’s faster and more reliable to host (Google) fonts locally on your server since you save the remote connection and download time.

And connecting to Google servers requires the web site visitor’s consent under European Union law.

Thanks for your input.

I did not use Blocksy’s Local Google Fonts feature.

Instead a Google font family, say “Alegreya Sans”, was uploaded via WordPress Media to Blocksy’s Custom Fonts feature.

Then, in Blocksy Customizer’s Typography panel *TWO* identical “Alegreya Sans” versions appear and you have no idea which is the custom local version.

And in Elementor, the custom font will appear correctly under the second section “Custom Fonts” (there is also an initial “Custom Fonts” section which is for Elementor custom fonts only). But the original font name has been changed from “Alegreya Sans …” to “ct_font_alegraya__sans…”. Now the question is who changed the font name – Blocksy or Elementor?

Further, I once deactivated and activated again Blocksy Pro (needed for Blocksy Custom Fonts), after which the custom font “Alegreya Sans” stopped functioning despite being still listed and defined.

This is the reason I’m now only using Elementor’s custom font feature because it works correctly and it does not require yet another “Pro” plugin. But Elementor custom fonts do not appear to work with Blocksy’s Customizer.

Nope, unfortunately there error still appears:

PHP message: PHP Warning: Invalid argument supplied for foreach() in /XXX/wp-content/plugins/contact-forms-anti-spam/admin/class-efas-admin.php on line 681

Seems I’ll have to deactivate Maspik again.

Thanks, your update seems to have fixed the PHP error!

Well, coming from old-school website development building sites from hand without any tools besides a text editor, it’s the lack of code discipline that bothers me.

I think the WordPress CMS itself is quite OK, aside from its still obvious history of having been developed as a blog management system. But it requires third-party plugins and to a lesser degree themes to match the requirements of today’s commercial web development. The coding restrictions set by WordPress for third-party developers appear to be very liberal. A majority of WP plugin devs are from emerging countries where the focus is on selling & cashing-in as quick as possible, and not on delivering reliable and streamlined products. Hence the many bug problems with even mature WP plugins. And then there is the code bloat problem leading to large Web files and slow performance.

There’s no redundancy control, no efficient coding framework when it comes to HTML/CSS/JS output on a WP system. On a simple HTML file with some text and a photo I can count 36 style sheets, and 75 scripts, which is astonishing. The more Web code the more electrical energy is wasted through routers, servers, browsers, and the user device. Multiplied by millions of users on a daily basis the waste is significant. And most plugins come with more features with each new version, leading to even larger Web output files, more database queries, and potentially more stability issues.

WP today is like a open-house kitchen where too many freelance cooks spoil the menu. The only way to solve the stability/performance issue would be for WP to come with a full-blown built-in page builder (optionally a pro version for a license fee), I guess. Or a close cooperation with a handful of selected page builder companies to ensure better code control. It does not help that WP was initially conceptualized as a plain blog management tool, which is in very strong contrast to what it’s mostly used today – eCommerce and dynamic web sites requiring a multitude of front-and back-end features.

On the other hand, WP is open-source hence free, which of course is great and therefor a big thanks to all participating developers for their time and efforts.

Thanks for your input, appreciated!

Problem is that most of the plugins (but no themes), including Woocommerce, use wp_enqueue_media in one or more of their PHP scripts.