Rework needed for SiteOrigin_Panels_Sidebars_Emulator class

Hello,

I’ve noticed, that on one website where we use your plugin, we had issues with using widgets on the home page content via page builder. I’ve traced down problem to SiteOrigin_Panels_Sidebars_Emulator class (method: register_widgets, lines:69-85), which is found in /siteorigin-panels/inc/sidebars-emulator.php file of your plugin.

Now lets take a look on the original code in detail:

function register_widgets() {
    $current_url = wp_parse_url( add_query_arg( false, false ) );

		// Detect current page id using path.
		if ( ! empty( $current_url['path'] ) ) { 

			// Check if WPML is running.
			if ( defined( 'ICL_LANGUAGE_CODE' ) ) {
				// Remove the current language code from path to avoid 404.
				$current_url['path'] = ltrim( $current_url['path'], '/' . ICL_LANGUAGE_CODE . '/' );
			}

			$page = get_page_by_path( $current_url['path'], OBJECT, siteorigin_panels_setting( 'post-types' ) );
			if ( ! empty( $page ) ) {
				$post_id = $page->ID;
			}
		}

1. First you check if path of the current url is not empty. I don’t know if there are cases when it actually could be empty, but I always get the url as “/” when visiting a home page, which is considered not empty, so the code runs.

2. By basing on existance of ICL_LANGUAGE_CODE constant you check if there is WPML language code defined to see if WPML is installed and active. This is old and dirty way to do it and WPML does not recommend to use this constant, since it will probably be removed in future. You should use wpml_current_language filter instead. Be aware also that the default site language could not have any language prefix in the url path – this also can raise some problems.

3. Now the most serious problem – Improper usage of ltrim function to get rid of the language code in the url path. PHP ltrim function accepts the CHARACTER MASK as a second parameter and uses it to remove every single character from beginning of the passed string. This means, that every letter which is written in second parameter of the ltrim function will be removed from the beginning of the url. In this case – if WPML language code is “en”, it will remove characters “/”, “e” and “n”. Now imagine what happens, when url path is “/ennie-foster/” – it leaves the trimmed path as “ie-foster/”. I’d recommend to use preg_replace instead.

4. Next – the WordPress function “get_page_by_path” is unreliable, because it does not always return the correct page object. It just guesses what does it need to return, and that could turn out messy. In our case it returned some “Auto Draft” post object on our site’s home page, which broke the layout of the page. I haven’t looked into probable solutions, but this should definitely be improved.

For now I’ve written a bit better version of this code (it does not cover everything i mentioned, but at least it is working now more reliably), which you can use in your plugin, but I highly recommend you to dig deeper and rework this “register_widgets” method in more detail:

	function register_widgets() {
		$current_url = wp_parse_url( add_query_arg( false, false ) );

		// Check if WPML is running.
		$wpml_lang = apply_filters( 'wpml_current_language', NULL );
		if (!empty($wpml_lang)) {
			// Remove the current language code from path to avoid 404.
			$current_url['path'] = preg_replace('/^\/'.$wpml_lang.'\//', '/', $current_url['path']);
		}

		// Detect current page id using path.
		if ( ! empty( $current_url['path'] ) && $current_url['path'] !== '/') {
			$page = get_page_by_path( $current_url['path'], OBJECT, siteorigin_panels_setting( 'post-types' ) );
			if (!empty($page)) {
				$post_id = $page->ID;
			}
		}

Regards,
Edgars