ext237

@aivanov12 This was reported a month ago, asking for someone to look into the issue. So asking to be provided the ability to toggle this specific check on and off is not “cheeky”.

@macmanx Some people work with 1 or 2 sites, some people work with a couple of dozen or more. Logging into 27 different FTP sites across various web hosts that clients are using, delete the file(s) on each one, do a full regression on the entire site to make sure nothing breaks, etc, isn’t the ideal resolution. Being able to disable this specific check could be helpful.

Is there a way to disable looking for old files? I’m getting this on almost all of the sites I manage. Getting tons of emails daily. Please fix or offer suggestions.

Oddest thing, after several days, items that were added are now showing up. We didn’t touch it all weekend, but I checked it this morning and it seems to be working. Maybe part of the save feature could be forcing a cash flush. There’s a couple of themes that do this as part of saving theme changes.

Unfortunately, due to several reasons, we stopped using this plugin for this site.

We build several sites a year and maintain for other clients, and “bots” have become a topic recently. If you can fix the “FAQ” issue and other issues, we will be back. If the FAQ setting is disabled, it shouldn’t appear.

During development, we don’t use our CDN or cache and dump browser cache when I encounter those kinds of issues. It did not resolve this problem. If you are using your own cache system, you may consider adding a “development”/”debug” checkbox, allowing people to bypass your cache while developing their bot.

Sorry, I meant the “From” address, yes. A) site owners may prefer to not have people know what software they are using, so “WordPress” does not appear in their emails. b) if someone has an address for sending emails through the website (such as no-reply@), they do not need to pay for another account for wordpress@ in order to use this plugin.

@soendber I certainly appreciate you helping us get back up and running with your fix. It’s concerning that it’s been 4 days without even a “we are looking into it” from the developers, considering it’s a full-stop site killer for those affected.

EDIT: They finally replied while I was typing this.

• This reply was modified 4 years, 2 months ago by ext237.

Yes, thank you for the fix suggestion, that should get a lot of folks back online with their forms. However, to be fair, this isn’t a repair and we need to hear from the developer that an official repaired version has been released.

Exactly the same. Running the latest version of all other plugins, theme builder and WordPress. Theme builder is Divi. https://ljlighthouse.com/

Per request, yesterday I sent you a copy of the theme via the email address you provided. Thanks!

I requested permission to send you a copy of the theme. I am waiting on the theme builder’s response.

hello.

• Information in brackets was removed because it’s not relevant to the question, the pathing of my server is not required to understand the issue.
• It is not unusual to obfuscate server pathing when asking questions on www.ads-software.com
• I did provide everything after the root of the website, which may be relevant to you to diagnose.
• The link to my store that you requested is included in the original bug report under the “The page I need help with:” section.
• There are a lot of reasons that a plugin can cause “Warning: Invalid argument supplied for foreach() in […]/wp-admin/includes/plugin.php on line 1732.”
• I’ve been an Ecwid client with multiple stores since 2014. Every time we send a bug report or ask that you look into an issue, the reply seems to always employ the issue is someone else’s fault.
• The theme (sub-themed) is DIVI, one of the largest WP Themebuilders. We add/update new plugins to various websites on a regular basis and contact the plugin maintainers when this error appears so they can fix it. Having to disable the theme for this ONE plugin is not an issue with the theme.

Ok, great, thanks. We rely on the link features, hope it doesn’t go away any time soon.

Interesting, I hadn’t considered The SaaS javascript aspect of page rendering, and how that would affect the ability to hook, filter and theme. With that in mind, it remains important that DOM structure not significantly change so we can use CSS and/or JavaScript to affect customizations.

The website I previously provided, HoustonPhotowalks.com uses some customizations, however another website, https://calidoguitars.com/ makes heavy use of customizations. I will compile a list of the customizations for you and reply back.

Thanks for the response and willingness to work with designers/developers of custom sites.

@mvbaxter there is no like button here, so I’ll reply with thank you.

I’m not a fan of adding custom CSS into a form field in an admin screen. It’s yet another thing that WP has retrieved from the database and echo into the HTML when a page is rendered. And in-line CSS is rarely the best scenario. Same for JS, having JS in an admin panel form field doesn’t really give you control over when the code is emitted.

However, taking your suggestion one step further, if we had the ability to give specific objects custom CSS class names in the admin panel, that would be helpful.

But, your 3rd suggestion offers a significant amount of flexibility. Also, if each section of the Ecwid interface was part of a themeable file that could be overridden in the theme directory, we could build our own interfaces completely.

I use a calendaring plugin on some sites that provide that customization option.

I already provided the requested information in my support email when our Ecwid sites all crashed. Those sites have been repaired and back online after removing the functionality from the 3rd party custom plugins, but here is a current example of issues I outlined.

Note the “drop shadow” included on the blog list on this page: https://houstonphotowalks.com/blog/

This interface element is used for consistency throughout the website.

A 3rd party calendar plugin “panels”, same drop shadow: https://houstonphotowalks.com/

A custom plugin to display advertisements, same drop shadow: https://houstonphotowalks.com/member-perks/

A 3rd party plugin to display “FAQ” items, also same drop shadow: https://houstonphotowalks.com/faq/

The above 3 plugins provide regular updates without changing class names or modifying the most basic structure of the HTML layout. This allows us to provide customizations that are stable and attractive.

The situation is different with the Ecwid store plugin:

https://houstonphotowalks.com/store/

Each category should have a white background with a drop shadow like the rest of the site. But because of the constant, arbitrary and unneeded class name and HTML structure changes every-single-time you update the plugin, the CSS has to be repeatedly edited.

As you can see, it looks like I need to go in and edit it. Again. Woocommerce sites don’t require me to budget time for rewriting basic css customizations when they provide updates and security patches.

So why does Ecwid?