ZappoB

Sorrily neither the disabling of YoastSEO, nor the change of the permalinks changed anything about this error. I tested the permalinks with “simple” (the page ids), and back again to post name, the shown dl link is always ?“https://mydomain.de/dhl_download_label/21290“, where it should say “…/wp-content/uploads/woocommerce_dhl_label/dhl-label-21900.pdf“.

I tried, but without any change.

Hi @niklasinpsyde,

thanks for coming back to me, it seems that V.2.0.5 has resolved the issue.

BR.

Oh, I found the “why”, hopefully you can name the solution:

The download link is “https://mydomain.de/dhl-label-21900.pdf“, but the path to the label is “https://mydomain.de/wp-content/uploads/woocommerce_dhl_label/dhl-label-21900.pdf“.

How can the path be set correctly? And: why does it have to be set at all?

BR.

Hi @abdalsalaam,

thank you very much, that was the solution. But it must also be said that the name of the option does not directly refer to the field in the checkout.

BR.

Hi @abdalsalaam,

you may have misunderstood me here, I would like to completely deactivate the display of the field, as this is already queried by another plugin (Germanized).

Hi @Bartek,

thank you for coming back to me. The frustration was not (I think I mentioned it somewhere) the design by itself, but the not few introduced problems (some minor, some major). As you state: you needed around 6 months to fix the issues of the V.3, instead of that, there had to be more (beta) testing and sub-versions 2.9.x.x. The 3.0 should have then only the new design with all functions working and till then fixing only the design bugs.

Just my 2 cents.

BR, Zappo.

Hi @bartek,

yes, the statement “no (!) other plugin shows even a similar problem” is a bit bold and should be reduced to “no other plugin we have in use shows even a similar problem”. And there are 72, not several hundred thousands.

Thanks for naming the REST API, as far as I could test it by now, disabling the caching of the REST API in LiteSpeed really seems to solve the problem. I don’t know, if this is the solution, because I don’t know, how much it affects the page speed, but at least there is a hint. I really would appreciate, if you can fix this, or find the answer with the LiteSpeed team. Just a thought.

BR, Zappo

• This reply was modified 1 year, 6 months ago by ZappoB.
• This reply was modified 1 year, 6 months ago by ZappoB.

Hi,

here an info for you:

Disabling the “display: flex” turns the icons visible.

Hopefully you can fix this in some of the next updates.

BR.

More information to the saved settings:

I enabled and then disabled in Firefox the option “enable outcomes clear”, it still shows enabled when reloading the page, also when opening the settings in Safari (completely independent).

But the setting I found in the database are looking like this:

shopmagic_general_settings

{“wpdesk_tracker_agree”:false,
“enable_session_tracking”:false,
“enable_email_tracking”:false,
“enable_pre_submit”:false,
“enable_outcomes_purge”:false,
“shopmagic_email_from_name”:””,
“shopmagic_email_from_address”:””,
“sm_enable_logs”:false}

——————————–

And now I have found the overarching connection: it is due to the Litespeed Cache plugin. After deleting the Litespeed cache, the options are displayed correctly.

Nevertheless, the question remains: why is this behaviour visible in the ShopMagic settings, no (!) other plugin shows even a similar problem.

To my knowledge, Litespeed only caches the frontend of WordPress and not the backend.

I now have a workaround, but I would be happy if you could investigate this strange behaviour on your site, as it only occurs in your plugin.

BR, Zappo

Additional information:

As reported, after deactivating and saving, the options appear activated again when the page is reloaded. This can be repeated as often as desired.

What I had already tested: deleting the browser cache does not help either!

New finding: after about 24 hours, the correctly set options appear in a new browser window. I don’t know if it’s a coincidence, but the settings that were deactivated yesterday are displayed correctly today. However, today it continues like yesterday: once activated options remain visible as activated, even if they have been deactivated, even across different browsers and systems.

We use Safari on macOS 13.2.1, but the error also occurs with Firefox 109.0.1,

Could it be a display error on the settings page? But it only affects ShopMagic, we don’t have any other pugin that also shows this problem.

Or could it be that the settings are saved with a delay?

These are just different ideas why this error is so tricky to track.

BR, Zappo

This error was introduced in V.3.0.7 or .8, in earlier 3 versions the name was still given correctly. I am not sure of the sub-version number, but it should be in this range.

I always use my user for tests, nothing has changed here. “Chattie s.” is a user that was only created for a chat system and has nothing to do with my account and therefore should not be displayed as {{ customer.name }}.

EDIT: i have found the connection: in the test orders i use the same mail address that the user “Chattie s.” has assigned. This may be inappropriate, but it did not lead to this error in the earlier versions <.6 of ShopMagic.

Has something been changed here so that the {{ customer.name }} is no longer taken from the actual address, but from “any” user with this mail address?

EDIT2: it seems you are now using the account username rather than the first and last name of the address. This sounds very unprofessional when the customer is greeted with “Hello username1234” instead of “Hello firstname lastname”.

• This reply was modified 1 year, 9 months ago by ZappoB.
• This reply was modified 1 year, 9 months ago by ZappoB.
• This reply was modified 1 year, 9 months ago by ZappoB.

Thank you for the explanation, but it shows me again that the decision to use Tiny (6) as editor essentially brings more problems than benefits. The standard WordPress editor worked perfectly, Tiny has no tangible added value, as unfortunately also the new design.

Here is the desired screenshot:

I have a bug here in the current version that is really annoying. Even if I repeat myself and fall on deaf ears: instead of designing a new, unnecessary GUI, the time would have been better spent developing the tried and tested version further. So far, I still cannot give a recommendation for V.3.

Regards.

And just as a reminder:

In the overview of “Automations” the icons to “Duplicate”, “Export” and “Delete” are not shown.

This icons still not showing up. Do you use a special font?

Good to hear. The souce code editor may then also work responsively.

Regarding point 2 above, the following information: line breaks and paragraphs are (still) missing in the source code view, but the source code of the mail is still correct. How can this be?

Greetings.