Forum Replies Created

Viewing 15 replies - 16 through 30 (of 123 total)
  • Thread Starter DensitySK

    (@densitysk)

    hi,

    I have tried. In fact we have launched a redesigned shop recently on a new and fresh database with clean install of wordpress. All plugins that were used on the previous shop are used on the new website as well (each was installed cleanly). Only difference between our new shop and the old one was the theme itself.

    However as I have noted previously, we have tried to disable all the plugins and the theme and have activated a default Woocommerce Storefront theme which has shown the same behavior in duplicating all the favicon files when we tried to upload them. So it is unlikely that the new theme is the issue. As the theme developer has already stated, they do not modify the favicon upload in any way and it is a WP core feature.

    WP installation and all the plugins are up to date.

    The debug mode was activated and only some warnings about PHP deprecated parameters are showing (the website on the frontend is working normally). Our hosting has recently been updated to PHP 8.4, so this is likely the cause for these warnings.

    Other plugins are not showing any errors.

    We have already communicated these php warnings to the theme developer who confirmed, that they will update the theme to solve this, but it is still unlikey that it is related to the cropping of the favicon in any way.

    Here are a few examples

    [11-Jan-2025 16:43:54 UTC] PHP Deprecated: Freemius::maybe_activate_bundle_license(): Implicitly marking parameter $license as nullable is deprecated, the explicit nullable type must be used instead in /data/xxxxxxxxxxxxxxxxxx/wp-content/themes/shopkeeper/freemius/includes/class-freemius.php on line 7780
    [11-Jan-2025 16:43:54 UTC] PHP Deprecated: Freemius::set_license(): Implicitly marking parameter $license as nullable is deprecated, the explicit nullable type must be used instead in /data/xxxxxxxxxxxxxxxxxx/wp-content/themes/shopkeeper/freemius/includes/class-freemius.php on line 12388
    [11-Jan-2025 16:43:54 UTC] PHP Deprecated: Freemius::switch_to_blog(): Implicitly marking parameter $install as nullable is deprecated, the explicit nullable type must be used instead in /data/xxxxxxxxxxxxxxxxxx/wp-content/themes/shopkeeper/freemius/includes/class-freemius.php on line 15633
    [11-Jan-2025 16:43:54 UTC] PHP Deprecated: Freemius::_activate_addon_account(): Implicitly marking parameter $bundle_license as nullable is deprecated, the explicit nullable type must be used instead in /data/xxxxxxxxxxxxxxxxxx/wp-content/themes/shopkeeper/freemius/includes/class-freemius.php on line 18112
    [11-Jan-2025 16:43:54 UTC] PHP Deprecated: Freemius::_store_site(): Implicitly marking parameter $site as nullable is deprecated, the explicit nullable type must be used instead in /data/xxxxxxxxxxxxxxxxxx/wp-content/themes/shopkeeper/freemius/includes/class-freemius.php on line 19711

    Thread Starter DensitySK

    (@densitysk)

    HI.

    please read again. And by the way I already did contact the theme developer as well.

    As I have clearly stated above, this issue persist even if I disable SHOPKEEPER theme and all the plugins, with only the WordPress, Woocommerce and the default Woocommerce Storefront theme active. Same issue happens even if I use other themes.

    Here is also the response from the theme developer>

    Adding favicon is native WordPress functionality and not something our theme handles. It could be permissions with your hosting and folders. Have you tried reaching out to them? (I am trying to do that now)

    Alternatively you can switch theme to Storefront (official WooCommerce theme) and see if the issue persists. If it does it’s a theme issue, if it does happen, it’s not a theme issue.
    (already tried, so it is NOT a shopkeeper issue).

    After further checking it seems, that WordPress is creating URLs or references to some cropped versions of the favicon, but not actually creating them. I see that various visitors are getting presented the favicon in different resolutions which triggers 404 error in the logs (while the website still works and is displayed, except the favicon).

    When I have checked the wordpress installation folders via FTP, I have noticed that all these cropped versions of the FAVICON are not present in the storage

    Thread Starter DensitySK

    (@densitysk)

    Additionally the SMTP report has started to acting weird.

    I have enabled the email reporting to be sent once a week. And in the recent days I am sometimes getting many reports from SMTP plugin in my email

    screenshot from my email below

    https://ibb.co/kDR2hrB

    Thread Starter DensitySK

    (@densitysk)

    Shopkeeper is not a plugin, but a theme, which is visible in the logs.

    Link to the theme is here

    https://themeforest.net/item/shopkeeper-ecommerce-wp-theme-for-woocommerce/9553045

    I have also noticed some mentions of the theme in the logs, but most of the backtracking came back to Post SMTP

    Thread Starter DensitySK

    (@densitysk)

    Hi,

    I am using the latest available version of Post SMTP Version 3.0.0. I am not using PRO version.

    Thread Starter DensitySK

    (@densitysk)

    Hi,

    I am using the most updated Version 3.7.38.

    I have re-entered the snipped and now the extra options have dissapeared.

    Looks like it is solved now

    Kind regards

    Thread Starter DensitySK

    (@densitysk)

    Ok. I understand. What I have noticed additionally, when I set the favicon via Elementor site settings, then it starts to work at least partially and some of the cropped image missing errors dissapear. But when I try it via the wordpress customizer (theme) it does not work and only create duplicates. So it might be an issue either with Elementor or the theme.

    Thank you for checking though.

    kind regards

    Thread Starter DensitySK

    (@densitysk)

    HI,

    Thank you for checking. Unfortunately this snippet did not work. I have tried it and still all the buttons are visible as before on the orders page and in order details on backend.

    Screenshot.

    https://ibb.co/wNgNNQV
    https://ibb.co/NCjMc5s

    Kind regards.

    Thread Starter DensitySK

    (@densitysk)

    Hi Peter,

    thank you for checking and the explanation. This makes sense. Probably I will have to use different wp-login url to prevent at least the basic bots. I am aware, that sophisticated attackers might still find out, but for that I trust Wordfence to do its job.

    However now that I have tried to use WPS hide login on my website, it was not working. Basically the homepage would s shop up but all the other links on my website lead to “no url found on this server” even though all the links are definitely correct.

    I have contacted the WPS hide login creator to check if this might be an issue with the WPS Hide login plugin itself. They responded that WPS Hide Login doesn’t redirect any link except wp-login.php and wp-admin for non-loggedin users. Moreover, WPS Hide Login doesn’t modify any other link.

    I know that WF is monitoring changes in core WP files and in .htaccess file. So I wanted to know if you might know about any WF setting, that might cause this weird behavior.

    Kind regards

    Michal

    Thread Starter DensitySK

    (@densitysk)

    HI,

    thank you fore checking, although your reply does not make sense.

    Does it mean, it could be an issue with a theme or images? Because all the generated 404s are from a cropped version of favicon. However my website is not using the name of the file for favicon. Also there is no reason for a human to access “by mistake” a non existing file or page and get 404 error tens or hundreds of times per minute.

    I am also using imagify, which is handling the serving of images and generating cropped versions. But I am not really confident, that this is just a theme issue, especially because of the amount of 404s generated

    regards

    Michal

    Thread Starter DensitySK

    (@densitysk)

    Hi,

    thank you for checking. This is incorrect. The issue is definitely caused by your plugin. Please read my previous description again.

    As I have already said, just deactivating your plugin did not fix the website (READ DEACTIVATE AND NOT COMPLETELY REMOVE FROM PLUGIN PAGE). I had to completely delete it via FTP and purge the cache again. After that my website was working correctly again.

    Every part of the website is working as long as the WPS hide login is not installed. As soon as I install and activate it, all pages except backend and home page result in URL not found.

    Maybe a side observation…when I install your plugin, the Wordfence Security plugin is requesting configuration and backup of the .htaccess file. Can it be that your plugin is not working well with wordfence security? Because as far as I know, WF is monitoring malicious behaviour and changes of the .htaccess file.

    I was using your WPS hide login plugin together with wordfence security plugin on a different website without any issues. So I am not sure what could be wrong here.

    Kind regards

    Michal

    Thread Starter DensitySK

    (@densitysk)

    Multistep je sucastou temy Xstore od 8theme, ktoru pouzivam. Zbieranie IP adresy je samozrejme sporne, pokial nie je osetrene a predovsetkym u sukromnych zakaznikov. Avsak u firiem je mozne (a nariadeniami EU VAT regulacie vyzadovane) za urcitych podmienok overovat IP adresu za ucelom zamedzenia podvodu pri odpocte DPH.

    Aj tvorca pluginu to uvadza v popise. Je nutne preverit minimalne dva nesporne zaznamy pred odpoctom DPH – napr. IP adresa v rovnakej krajine ako VAT ID a zadanie spravnej adresy registracie firmy.

    https://ibb.co/mc0cXPp

    A minimalne IP rozdielne od krajiny registracie firmy moze spustit dodatocnu validaciu a self-certification, ktora je v niektorych krajinach EU povinna (napr. dodatocne checkboxy).

    Nasledne vidi admin webu v detaile objednavky takzvane Consultation Number ako na screenshote. Toto moze byt pouzite v pripade danovej kontroly pouzite ako dokaz, ze prevadzkovatel v momente objednavky spravil co bolo v jeho technickych moznostiach, aby overil spravnost VAT ID predtym, ako odpocital DPH

    https://ibb.co/YLvwwpt

    Thread Starter DensitySK

    (@densitysk)

    Dobry den,

    mate pravdu, moj kosik ma multistep. Problem nastava presne v tom, ze v prvom kroku je predvolena krajina Slovensko (domovska krajina eshopu). Preto zakaznik ak najskor zmeni krajinu a potom zada svoje VAT ID, tak vsetko prebehne OK. Ale ak nahodou najskor zada svoje VAT ID (s preklepom) a az nasledne zmeni krajinu na spravnu volbu a doplni ostatne fakturacne udaje, tak kosik ho upozorni az ked sa dostane na posledny krok a chce odoslat objednavku. Az vtedy vyhodi chybu, ze napr VAT ID je neplatne a musi udaje vyplnit znova a tento raz spravne.

    Na teraz to ale neriesim dalej, lebo som presiel na iny plugin, kde kontrola formatu a overenie cez VIES funguje v realnom case a v prehlade objednavky v admine vidim aj IP a datum overenia VAT ID aj s identifikatorom od VIES, ktory sa da pouzit aj ako dokaz pri pripadnej danovej kontrole (jedna sa o https://wordpress.org/plugins/woocommerce-eu-vat-assistant/)

    Zatial dakujem.

    Thread Starter DensitySK

    (@densitysk)

    Dobrý deň,

    malý update…vypnutie a zapnutie Enable VAT exemption for valid EU VAT numbers v nastaveniach Kybernautu zafungovalo a teraz aspoň odrátalo DPH pri AT firme. Ale všimol som si, že aj keď je nastavenie zapnuté a zákazník počas Checkoutu zmení napr. krajinu a znova zadá svoje VAT ID, tak systém už DPH neodráta, alebo musí sa dostať až na posledný krok na odoslanie objednávky a až vtedy plugin vyhodí chybové hlásenie, že VAT je neplatné.

    Rovnako si stále nie som istý ohľadom overovania vo VIES. Je nejaká možnosť, aby do objednávky vložilo nejaké potvrdenie o kontrole VAT ako to robia napr iné pluginy, ktoré validujú cez VIES?

    https://wordpress.org/plugins/woocommerce-eu-vat-assistant/

    Thread Starter DensitySK

    (@densitysk)

    Example parcel ID from a shipment from last week is 06535611986295

    Old tracking link>

    https://tracking.dpd.de/status/en_SK/parcel/06535611986295

    New tracking link>

    https://www.dpdgroup.com/sk/mydpd/my-parcels/incoming?parcelNumber=06535611986295

    It seems that the old DPD tracking link in Slovakia is working only with old shipments and not with the new ones.

Viewing 15 replies - 16 through 30 (of 123 total)