djnz0813

Hi, that was because I was getting the server configuration error message. But I see that for Siteground, the Nginx delivery has to be disabled. I did that, switched back to the htaccess method and indeed the -optimized suffix is gone and the images are showing.

Thank you.

Experiencing the same issue on a multisite installation. The solution for the moment is indeed to network de-activate from the main site and activate individually on the individual sites.

I found it. It was a custom function I had wrote that I forgot about.

Fixed, thanks.

Thank you, that’s exactly what I needed.

As for question # 2, I see that the league ids are not the same on dev and production.

On test I am using leagues with ID # 2 and 6, while the live site has leagues with ID # 1 and 4. I guess I understand now what is going on.

But my first question about the username / nickname display remains…

Maybe what I am trying does not make much sense.

WE have one main league which is linked to prizes, but we also wanted to give players the chance to create their own private league. I have a way to let someone create their own league without being an admin, but for that to happen, they need to not be entered automatically into a league.

So the idea was to have a drop down on the sign up page where you select to be added to the main league (for the prizes), or say no league (so you can create your own). You then log in and create your own league.

This approach is giving two issues however. 1) Everyone is being added in the same league regardless of choice. 2) I still would not know how you invite / add your friends after you create your private pool.

Yes, I went through all those posts but I’m getting stuck on one thing. I basically want the user to select between two options. Either join the main league, or join without entering a league.

Right now, whatever the user selects, he will always go into my league which has ID = 3. When selecting the other option, he will still be entered in that league.

I’ve been staring at that code snippet with the cases, and I can’t seem to see what I’m doing wrong. All I need for now is that they don’t get assigned to that one league if they choose the other option in the drop down.

I’m sorry for jumping in your thread but I see that you mention solving how to define the leagues in the sign up form, so users do not see or choose the league.

May I ask how you did that? I’m trying the same thing using UM registration plugin, but I can’t seem to get it to work.

Thank you! That worked perfectly.

Hi Andrea,

That seems to do the trick! Thank you very much ??

I purged all the cache (CDN included) and immediately re-uploaded all the background images again. For now everything looks good, but I will check again tomorrow.

I have 5 other multi-site setups and none have this issue, even though the caching on all of those are way more aggressive. Makes me think that it could be Cloudflare related as the others are not on Cloudflare, while this one is.

I understand. Geen probleem. Bedankt nogmaals voor alle hulp en suggesties. ??

I was checking in Edge and Edge was giving a mixed content warning in dev tools, even though it was “padlocked”.

“Even though the initial HTML page is loaded over a secure HTTPS connection, some resources like images, stylesheets or scripts are being accessed over an insecure HTTP connection. Usage of insecure resources is restricted to strengthen the security of your entire site. To resolve this issue, load all resources over a secure HTTPS connection.
1 resource
Name Restriction Status
header.jpg automatically upgraded”

The header.jpg name is the old file, so Edge is also loading the old headers and automatically upgrading it. I guess Brave and Chrome are also doing that, while Firefox is not.

So, it really must be a caching issue by the looks of it.

Yes, I renamed the headers and uploaded them again, but I didn’t delete the old ones from the media folders (it’s a WP Multisite setup).

This is the odd behavior as of now….

Chrome mobile (browser cache not cleared) – padlocked and good
Samsung mobile (browser cache cleared) – padlocked and good
Chrome desktop (browser cache not cleared) – padlocked and good
Brave desktop (browser cache cleared) – padlocked and good
Edge desktop (browser cache cleared) – padlocked and good
Firefox desktop (browser cache not cleared) – css loading the version of 2020
Firefox desktop (browser cache cleared) – css loading the version of 2020

Do you mind sharing your email with me? I’d rather not share these corporate pages where this is happening here.

Spoke too soon. Two days later and the css files are loading the old headers, which were uploaded in 2020 (with non http). I will clear all cache (server and CDN) again and if that does not solve the problem, I really won’t know what else to do.

Dit is toch niet normaal?

My apologies. You are correct.

After the PayPal payment, the customer can click on the “return to merchant” button and they then get returned to the order received page (of that particular subsite).

Unfortunately, that does not fix the payment referral problem. But I will try something else to fix that. That is a Google Analytics issue, not a Woocommerce or PayPal issue.

Thank you for the help.