lospeso

@lianakap

Thanks for the info/response.

None of the troubleshooting items you listed worked, made no difference, the problem persists.

FYI, I used the shortcodes in a basic WordPress page, no Elementor, the problem occurs there too.

I already checked/tested:
– plugins,
– theme,
– Used Default WordPress theme,
– cleared caches: browser and server,
– even had the hosting service check their server/settings for problems,
– problem only occurs on that domain (where the test website is located)
– problem does not occur on another domain (tested by someone else)
– problem does not occur in localhost environment,
– problem only occurs when using WordPress 6.0,
– problem does not occur when using WordPress 5.9.3.

The part that stumps me is when using the shortcodes in the Elementor Editor, they work perfectly, but they do not work in the actual page of the website.

Note: the test site is a subsite of the main website, so both are using the same domain/hosting account.

Questions:
1. Why do the shortcodes work in the Elementor Editor, but not on the actual website page?
2. Any suggestions of anything I can check to troubleshoot this as to why it is not working in WordPress 6.0 on only this one website, after all that has already been done?

I hope you can help.
Thank-you.

@lianakap

Here is a link to that page.

Shortcode/Elementor Issue – Test Page

Thanks

@weboccults
Cancel my post above and my questions in it. >>> I found the cause to the problem.

I went to a different server and repeated the test there.
Voila, the short-code syntax works, even in WordPress 6.0

See this screenshot (opens in new tab):

https://prnt.sc/Ev46kDfCA6nt

Why does it work on a different server?

I noticed in your screenshot image that you used a localhost setup to test and demo WordPress.

Based on your screenshot, I already had my own localhost setup, so I tested the shortcodes on my localhost to find the shortcodes worked fine.

The new test I just did on “localhost” (my own computer hard-drive), I used Laragon to provide the PHP environment (v7.4.30) and Apache server (v2.4.47) setup. The PHP version I used on localhost is the same version currently active on the website hosting service I use.

Its not the PHP version, since they are the same between localhost and them, so the website hosting service has something else there that I don’t have on my localhost that causes the problem with the shortcodes.

I will contact the website hosting service I am using, and try to find out what is on their server causing the issue.

Thanks for your help.

@weboccults

I am using the exact same coding you show in your example, for both shortcodes.

/**SHORTCODE - DATE*/
//Use short-code: [pp_cat_list_date]

function my_list_categories_shortcode_date() {
   ob_start();

    echo "Date Shortcode";
    $dateARG = array( 
	//Date ID = 19
	'orderby' => 'name',
	'exclude' => '1,18,20,21,22,38',
        'order' => 'ASC',
	'show_count' => 'true',
        'echo' => 1,
        'hide_empty'=> false
	);
   wp_list_categories( $dateARG );
   $html = ob_get_clean();
   return $html;
}
add_shortcode( 'pp_cat_list_date', 'my_list_categories_shortcode_date' );

/*SHORTCODE - INSTITUTION*/
//Use short-code: [pp_cat_list_institution]

function my_list_categories_shortcode_institution() {
   ob_start();

    echo "Institution Shortcode";
    $institution_arg = array( 
    // Insitution ID = 18 ,
    'orderby' => 'name',
    'exclude' => '1,19,20,21,22,38',
    'order' => 'ASC',
    'show_count' => 'true',
    'echo' => 1,
    'hide_empty'=> false,
);
  wp_list_categories( $institution_arg );
  $html = ob_get_clean();
  return $html;
}
add_shortcode( 'pp_cat_list_institution', 'my_list_categories_shortcode_institution' );

//END - CREATE SHORTCODE CATEGORY LIST PAGE

The same problem occurs for both simple page and simple post.
Plugins are not the cause, I tested it.
I am using the basic default WordPress theme.
Yes, I purge the cache and used a hard reload of the browser (CTRL+F5)

Questions:
Are you using WordPress version 6.0?
What would normally or generally cause the query for the second shortcode to fail and show as “No Categories”?

Thanks

@weboccults

I really thank you for the time your spending to help out.

I duplicated everything you had for my test on two shortcodes.
One shortcode was for “Date”, the second for “Institution”.
I used the basic WordPress theme Twenty-nineteen and placed them into a basic page, where the Date shortcode was first and the Institution shortcode was placed under it as second.

Like this:

[pp_cat_list_date]

[pp_cat_list_institution]

The same problem occurred, except one difference.

Due to the added arguments,

'echo' => 1,
'hide_empty'=> false

…the second shortcode (Institution) displays as “No Categories”.
The added arguments revealed what WordPress was doing.

WordPress displayed only one shortcode, the first one (Date) on the basic page and then did not pull the data and display for the second shortcode (Institution), instead it rendered the second shortcode as “No categories”, which is false.

The “No categories” display is false because when I switch the shortcodes around (ie: make Institution as first), then all categories do display for that shortcode where the second shortcode (Date) displayed “No categories”, again a false result.

Here is the screenshot:

https://prnt.sc/4S5SP6sk3WPn

Is that what you got with your test?

@weboccults

Thanks for the PHP you wrote, unfortunately, it did not work.

@bcworkz
“‘echo’ => 0,” did not work at all, made no difference.

Returning to what I said in my initial post, I created 7 shortcodes to work individually to show/display on a page a specific category and its children. The shortcode PHP I wrote was to exclude all other parent category ID numbers and only show the category (ID) specific to the shortcode.

As mentioned, before WordPress 6.0, the custom PHP I wrote worked without a problem and has worked all along until 6.0 came out.

This says something in WordPress 6.0 has changed that made “wp_list_categories”, which is what each shortcode depends on, to stop displaying results for all shortcodes, except one.

In other words, only one shortcode will show results, which is the first shortcode listed on the sitemap page, and the rest will not work.

Example, on the simple page in WordPress:

[shortcode_one]
[shortcode_two]
[shortcode_three]

…only shortcode_one will work, the rest won’t. If I switch the order around making another shortcode the first one in the order, that will show results, the rest won’t.

What I did now, was make a few changes to the custom PHP, to ensure as best I could, that each shortcode using the same “wp_list_categories” function, should only show the categories that shortcode function is suppose to show.

Here I show 2 of the seven shortcodes:

/**SHORTCODE - DATE*/
//Use short-code: [pp_cat_list_date]

function my_list_categories_shortcode_date() {
    $date = array( 
	//Date ID = 19
	'exclude' => '1,18,20,21,22,38',
	'orderby' => 'name',
    	'order' => 'ASC',
	'show_count' => 'true',
);
   wp_list_categories( $date );
}
add_shortcode( 'pp_cat_list_date', 'my_list_categories_shortcode_date' );

/*SHORTCODE - INSTITUTION*/
//Use short-code: [pp_cat_list_institution]

function my_list_categories_shortcode_institution() {
    $institution = array( 
	// Insitution ID = 18 , 
	'exclude' => '1,19,20,21,22,38',
	'orderby' => 'name',
    	'order' => 'ASC',
	'show_count' => 'true',
);
  wp_list_categories( $institution );
}
add_shortcode( 'pp_cat_list_institution', 'my_list_categories_shortcode_institution' );

Even with those changes, the problem persists, only the first shortcode will display on the page and the rest won’t.

This says that something in WordPress 6.0 is different than before, allowing only 1 shortcode to work and blocks (or ignores) the rest.

Since 6.0 is coded differently, my custom coding has to change to match it or there is a bug in WordPress 6.0. I am leaning more to the latter, there is a bug.

Does what I wrote above help clarify the issue?

@weboccults

Thanks for the info, but unfortunately it did not work.

Only one of several shortcodes display the results, as described above.
I did follow the syntax in the WPBeginner.com article you linked, but alas, no difference.
…and yes, it is used in a text editor, in fact I tested it in the classic text editor in WordPress, problem remains the same.

As mentioned in my original post, all worked great until WordPress 6.0 came in, then this problem with the shortcodes occurred.

I am wondering if the following part of the PHP has anything to do with it?
This part:
'exclude' => '1,3,7,21,277,365',

Any ideas?

Thanks for the reply.

I did not mention it, but at the time of my original post, I did check for a box shadow setting and there was none, especially since I did not use such a setting. I also went to the browser inspector to find where this was being generated, it came up as a SVG, (which is what Elementor uses to create the Shape Divider effect), and there was no box-shadow in any of the CSS for that specific element or elements around it.

As a result I moved to not use the Shape Divider and instead used Custom CSS – Clip-path property. This achieved the design I wanted and not create the grayish line. So moving out of Elementor to Custom CSS resolved the issue as a work-around.

Yet, now that you replied to this post, I went back and created a test page using the Section element giving it a background image. Then used the Shape Divider for that Section and it created the same shape at the bottom without the grayish line as before.

What has also occurred before your post, Elementor did update and obviously something changed. The grayish line does not appear now.

I guess this is resolved, but how exactly, I do not know.

Thanks.

It has been 1 month, is someone from Elementor going to answer my request?

Thanks for the reply.

The update to v3.7.5 was good. It did not reset anything.

Since the issue did not occur on the current update, likely means the reset issue was due to some unknown random glitch during the update to 3.7.4.

A similar kind of glitch we see in loading a website page, it failed to load properly until the page is reloaded again to fix it, saying that maybe a script line or two failed to complete on the 3.7.4 update, which led to the reset issue.

For now, the issue somehow got resolved.

Thanks

Your promise to notify the developers to address the issue is fine.

Appreciate your help.

Thanks.

@wpmudevsupport12

Suggestion
I would then suggest to add this setting/adjustment to the plugin to allow the user to set the slide-in-box position the way they need it.

Keeping it locked (to non-CSS users) to the current positioning really does restrict its usability.

Thanks

• This reply was modified 3 years, 1 month ago by lospeso.

@wpmudevsupport12

Thanks for the reply and confirmation.

I understand the need to have it fixed, but still this leads to a question.

“Do you expect the general user, with no CSS experience/knowledge, to fix this issue when it should already be included within the plugin CSS design to ensure its visibility, however you choose to design it?”

Thanks

@mateithemeisle

Thank-you!