nachtigall

Same error here. I guess either DHL has change its API (and the plugin is not updated yet) – or DHL server is broken.

The source code of the plugin still refers to the now 404 link:

https://github.com/shadimanna/dhl-logistic-services-for-woocommerce/blob/9d4cecf7e493e032cf59f4c1049457519d382e4e/pr-dhl-woocommerce/pr-dhl-woocommerce.php#L152

		$this->define( 'PR_DHL_PAKET_TRACKING_URL', 'https://nolp.dhl.de/nextt-online-public/report_popup.jsp?idc=' );

Let’s see what the plugin author says…

yeah, don’t worry, I’ve found a solution by now. I surely could have done it myself with some JS but am short of time at the moment.

Just for the record: We have no control over the varnish instance, it is provided by our hoster GANDI and has this setup, see here: https://docs.gandi.net/en/simple_hosting/common_operations/varnish_cache.html#cookies

I know some other hosters use something similar, e.g. https://pantheon.io/docs/caching-advanced-topics

But I understand that this is maybe not the usual setup.

Wow, that’s fast. We will re-consider for the next time. However, since according to the FAQ this was done using a cookie, this is a showstopper for us: We use varnish (provided by our web hoster) in front of our wordpress for Caching. And whenever a Cookie (that is not Google Analytics or other well-known cookie) then the Caching will fail (“MISS”).

So like I wrote before, for us it would be better if the browser’s localstorage would be used for this. https://medium.com/swlh/cookies-vs-localstorage-whats-the-difference-d99f0eb09b44 and by default the banner is hidden and only shown via JS when a certain localstorage setting (like “SimpleBanner_userClickedClose”) is not present.

Anyway, thanks for the plugin. It is good to have choice. You might want to add also an FAQ item “Does this banner plugin offer a close button?” (Answer: YES) as I have seen this question pop up in other plugins’ support threads too and not many seem to offer it.

fwiw, I went with https://www.ads-software.com/plugins/bulletin-announcements/ now.

Hi @rpetersen29

I would also need the close button to display some corona lockdown infos… Maybe I’ll do it myself with some JS, but I do not have much time now. So consider this a +1 ??

Anyway, related to:

Additionally I would need to implement some type of data storage in users’ browsers (most likely cookie storage) to ensure that the banner doesn’t show up again while the user is browsing the site. Cookie storage involves some GDPR issues, https://gdpr.eu/cookies/, which I don’t necessarily feel comfortable forcing upon users of this plugin.

For storing info in the browser it would be better to use local storage (or session storage) and handle it only with JS/CSS. In my opinion there is no need to send cookies to the server (which would also make Caching very hard).

Thank you for answering and considering it! I’m setting the topic to “resolved” and will wait for the future version.

Also, do you have the source available on github (preferred) or somewhere else?

• This reply was modified 7 years, 1 month ago by nachtigall.

I think I found a solution: Immediately after importing the mysql live dump to testing I could change the live key strings to the test keys (mysql update).

I just need to know where these are store in MySql? (table, “row”/”id”). Can you let me know? I could not find it myself.

Danke!

Ein PS:
Du schriebst weiter oben:

Eigentlich ist die Verwendung von remove_filter schon korrekt. Einen 4. Parameter erwartet die Funktion allerdings nicht, s.
https://codex.www.ads-software.com/Function_Reference/remove_filter

Allerdings finde ich im Code von euch diverse Stellen, wo remove_filter mit 4 Parametern aufgerufen wird:
* https://github.com/vendidero/woocommerce-germanized/blob/580ff9f642148090b26c7a91ada1097b3f7a0597/includes/wc-gzd-template-functions.php#L266 und folg. 2 Zeilen
* https://github.com/vendidero/woocommerce-germanized/blob/13ce312fd724718e7ce8f4e987870469e739cd09/includes/class-wc-gzd-customer-helper.php#L270
* https://github.com/vendidero/woocommerce-germanized/blob/72d0dc868793c803674c12e0b703781cd2e3b8a1/woocommerce-germanized.php#L753

Aus Interesse: Sind das Fehler? die von WP stillschweigend ignoriert werden?

PPS Ich denke, die Frage k?nnte auf “resolved” gesetzt werden

Hi Lars,

Are you using in your staging system the live or the test keys
from PAYMILL?

Yes, sure. How else am I supposed to dump live to testing? That’s what the whole question is about in my last comment, you could just replace the term “deinstall paymill” with “remove live keys from live server” and have the same problem still.

In case you are using the live ones then it will also overwrite the destination for the live Webhooks with the staging url once you save the keys. Might be important as well to keep this in mind, so that it will not generate unwanted side effects in your live system.

As pointed out: This is exactly what happens.

It is not required to stop or deinstall PAYMILL on the live system, you only have to make sure that you use the proper (test)keys for the staging system.

So I do not have to deinstall paymill on the live system, but remove the live keys from there before dumping to a test system? See last comment. This is (almost) equally bad.

Have a nice day, too ??

Ich habe genau dasselbe Ansinnen:

4 Fragen da:

1. Kann man dafür in den Germanized-Einstellungen bei Grundpreis nicht eine Option (Checkbox) schaffen wie z.B. “Grundpreis auch in E-Mails ausgeben”

2. Ist das mit der CSS-Methode safe? Ich frage, weil unterschiedliche Mail-Clients ja Probleme mit CSS haben sollen (https://github.com/woothemes/woocommerce/pull/6489) Deshalb wird normalerweise ja nur CSS-Inline bei Mails verwendet

3. K?nnte man das nicht wenigstens umbrechen in der Mail, also Grundpreis kleiner und auf eigener Zeile schreiben. Aktuell sieht es wirklich nicht sch?n aus, screenshot aus Thunderbird: https://i.imgur.com/xs1E41j.png

4. Ist das rechtlich in einer Mail wirklich n?tig, dass der Grundpreis ausgeben wird?

Knappe Antwort reicht, sch?nes WE ??

Hi Matthias,

thanks for the reply, not sure if I really understood it.

I do not install paymill on a test environment. What I have is a working live server. Whenever I do big upgrades of WordPress, WooCommerce Core and plugins (among which is Paymill), I first test this on a dev system. This is what’s recommended: https://docs.woothemes.com/document/testing-updates-using-a-staging-environment/

How can this still be done? Am I correct – from reading your reply – that Paymill has to be deinstalled from the test system as soon as the live system is dumped to the test system? If so, how can I make sure Paymill has not yet overridden/registered the working webhook with a wrong localhost URL?

So basically, to be really sure that paymill never touches the test system I would need to
1) deinstall paymill from live
2) dump live (without paymill) to testing
3) reinstall paymill to live

Is this correct?

I do not know what causes the overriding of the webhook in the first place. I did not take any action (except updating), it happened automatically. Wouldn’t it be easier in the first place if this automatic webhook overriding did not happen?

Issue is not pressing, have a nice weekend ??

Best regards,
Jens

ok, just setting to “Produkte” seems to be enough then.

Totally agree, multi language support is extremely buggy in woocommerce, no matter what clue plugin you take (wpml, polylang…).

But this stems more from poor multi lang support in WordPress itself than WooCommerce to be honest. Problem seems that WordPress is very much US-centric whereas in the rest of the world you want at least a two language website in most cases…

the share counts wouldn’t work anymore as long as WP_DEBUG is true

Then you would just check for this ??

if ( defined( 'WP_DEBUG' ) && WP_DEBUG == true ) {
    // set to false
}