Norm Sash

Yes, I’m aware of the migration plugins and do use them, as well as the shortcode in menu plugin.

This is a specific use case in which I want to return the site_url in the menu item.

The shortcode that I created [site_url] shown earlier in this thread works fine when placed in a post (e.g returns https://mydomain.com) but when put in a nav menu item returns https//mydomain.com (missing :).

Maybe there’s no answer to this problem. Closest is what @berksted hinted at: being that WP is stripping “:” out of the nav menu item because it thinks it is a special character.

Thus, I’m wondering if there is any WP filter that might allow me to modify the list of “special” characters and allow the “:” to pass. I haven’t found one but I could certainly be missing it.

Thanks Ben, that is helpful. However, I don’t see a way to add the menu items via filter as working very well for me.

On several of the sites I’m trying to make the custom menu items more resilient to changes in site_url locations.

For example, I have a WP site at mydomain.com/production. I then clone that to a WP site mydomain.com/stagging.

In that case, all custom menu items that were entered in the /production site would still be pointing at the /production link. What I want them to do is update to point to the /stagging install (just like the nav links to posts do).

That’s why I’m trying to use the shortcode [site_url] which returns the WP site url address.

So in the nav custom link if I just put something like [site_url]my-account/ it would always return the proper url link no matter what site location I’m using.

And it works great – except for one thing… the stripping of the colon out of the url link. Slashes are retained just fine, it’s just the colon that is missing.

Is there maybe a filter that would allow colons and not treat them as special characters?

To clarify a bit more… I’m adding the shortcode into a nav menu custom menu item similar to this in the url field of the menu item:

[site_url]my-account/

… and if you then examine the url of that menu item when it is rendered, it renders something like

http//mydomain.com/my-account

… again, missing the : colon

Thanks qtwrk! I tested it out and that worked – removed the data-no-lazy from all the elements. I only made one small change to the code for the attrib. Here’s the code I used:

function remove_data_no_lazy( $content ) {
   $content=str_replace( 'data-no-lazy="1"', '', $content );
   return $content;
   
}
add_filter( 'litespeed_buffer_before', 'remove_data_no_lazy', 0);

Thanks again.

Yeah, I’m using a page builder and the module vendor put in the no-lazy-load attrib because there was another caching service (not Litespeed) that was having difficulty rendering galleries. So the vendor added it to all of the various grid modules.

I’ve done some testing with Litespeed, and with the combination of LQIP and lazyload I’m not seeing the same issues that were reported with the other caching service.

So I can either go back to the page builder vendor and ask them to modify all of their various modules to add in a WP filter, and then put in my code the filters for all the various modules… or I can just globally disable the no-lazy-load and then add a CSS class or selector to force lazyload exclude anywhere I notice a problem.

… at least that was my plan

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

Thanks for the response. I thought that might be the answer. Thanks for letting me know where in the source I can look… I will only modify it for testing purposes though so I can try out a couple of things.

Maybe this could be added as a filter or option at some point.

Thanks,
-Norm

Thanks Scott. I have PHP opcache but not memcached or redis on the server (shared host doesn’t enable memcached). I’ll try the Alternative Cache plugin and see how that goes.

Hi beeky2,

I would like to request that this be made a feature in the SWAL settings to have the SWAL menu item displayed or not.

Thanks,
-Norm

Thanks Beeky2. I just deleted and reinstalled the plugin (there was not an update notice like you suspected) and it worked. Looks like the fix to the original problem is done so we can close this topic.

Hi,

I just recieved the update Version 1.8.5 but the fix for login compatibility with Shield active wasn’t in that update :(. Was it supposed to be, or is there another update yet comming?

Thanks,
-Norm

Hey Beeky2,

Thanks so much for the follow-up and something for me to test. I’ve made the change you suggested and so far it is working much better with Shield.

But it expossed another problem…

If I have both SAL and AM360 (ActiveMember360) enabled, just trying to view the homepage of a site I get a constant redirect loop of login >> login/ >> login >> login/ >> etc, eventually ending up with a 500 error.

That only happens if both of those plugins are active at the same time. If I disable either plugin then there is no redirect at all, that is, I don’t see any attempt to redirect to any “login” or “login/”. I can’t figure out where the redirect to “login” or “login/” is being triggered because I don’t see that in the configuration for either plugin.

Any ideas or something that I can try?

Thanks,
-Norm

Hi Beeky2… Thanks for looking into this. Let me know if there is something you want me to test or a workaround. I would love to use your login, however this issue is preventing me from using it as users can’t login.

Thanks,
-Norm

Follow-up… I received the following response from the Shield developers:

`We’ve taken a look at this plugin and unfortunately we’ll not be able to support it – you’ll probably need to contact the developer if you haven’t already.

The issue comes with WordPress load timing and how they’ve integrated with WordPress.

We guess because they want to “speed” things up, they’re hooking into “after_setup_theme” which fires very early… even before “init”. Our hooks that capture logins etc. aren’t setup by then (they’re setup by ‘init’).

We’m not sure why they’re not hooking into the WordPress AJAX system in this particular part of the processing.`

• This reply was modified 3 years, 4 months ago by Norm Sash.

Thanks for the pointer, Jory. Clearing out the Pods cache resolved it… I didn’t think of that as I had deleted the Pods cpt “Courses” a long time ago (like a year ago) so didn’t think at all that cache would still be hanging around.

Again thanks for the pointer… it seems to be working now.

Hi Jory, thanks for the reply.

I don’t really need to change the name of the CPT; I was just thinking that might be the path to resolving the real issue. So let me focus on the real issue instead and then maybe you can provide some pointers.

As mentioned in the OP, when I extend the LearnDash CPT via Pods, for some reason it also forces a change in the permalink structure. What I mean is that I have the LD permalink settings configured to show permalink as //mydomain.com/courses/xxx and that works fine when Pods is not enabled. But as soon as I extend the LD cpt with Pods then the permalink structure for all courses is forced to //mydomain.com/sfwd-courses/xxx. I then can’t find any way to set it back to using just ‘courses’ for the permalinks even though it is set that way in my permalink > LearnDash settings.

One thing that might be impacting this… On the site I used to have a Pods defined cpt called “Courses” (e.g. mimicking the LD Courses / Lessons / Topics). I decided to instead just go with LD so I deleted the Pods CPTs for Courses, Lessons, Topics and then installed LearnDash.

Is it possible that there are still vestiges of the Pods cpt for Courses hanging around somewhere even though I deleted it and it doesn’t show up in Pods admin? Could that then be causing some conflict and forcing a change to the permalink structure?