bfarber

Thanks for bringing this to our attention. I'll take a closer look at this for an upcoming release.

FYI, if you have a word set to loose (such as the one you have right at the very top of your screenshot), you do NOT need all the stemmed versions of the word too.
An example not using a legitimate bad word: if I have a loose bad word filter for "top" then this would cover all variations such as "topped", "topping" and "tops", as well as any words containing the root word, such as "stop". A loose filter loosely matches the word, so I would remove all of your extra variations. They will simply cause the parser to require more work performed with no benefit whatsoever (i.e. your server is wasting resources).

We have adjusted the caching for this widget for 4.5.

I can confirm a fix for this issue was committed - it apparently hasn't been released yet, but should be included with 4.5.0.
 

Thanks, I've logged a bug report to have this looked into.

This is due to a change on Google's end, which we will account for in 4.5.
 

This is due to a change on Google's end, which we will account for in 4.5.
 

Review data used to be valid for Article object types in structured data, but Google has since changed their mind and no longer allows you to include review data for articles. We are looking into this.

Review data used to be valid for Article object types in structured data, but Google has since changed their mind and no longer allows you to include review data for articles. We are looking into this.

Review data used to be valid for Article object types in structured data, but Google has since changed their mind and no longer allows you to include review data for articles. We are looking into this.

Thank
Thanks!!!!
In my case , everything id nicely printed to PDF by using the following:
@media print { .ipsBreadcrumb.ipsBreadcrumb_top, .ipsBox_alt.ipsPhotoPanel, html[dir="ltr"] .ipsFollow, .ipsList_inline, .ipsList_reset, .ipsBreadcrumb.ipsBreadcrumb_bottom, .ipsGrid.ipsGrid_collapsePhone.ipsPager.ipsClearfix.ipsSpacer_top, .ipsItemControls, .ipsType_reset.ipsType_medium.ipsType_light, hr.ipsHr, .ipsTabs_panels.ipsTabs_contained, .ipsTabs, #ipsLayout_footer, #elCopyright, header { display:none;} .ipsBox { border: none; } .ipsLayout_container { padding : 0; } }  

In the AdminCP under Customization > Themes, click the </> icon next to your theme. On the template editor page click the CSS tab, and then click on custom.css.
Add this to the end of the file:
@media print { /* Custom styles go here */ } And then add whatever CSS you need to (i.e. to hide unimportant page elements) where you see "/* Custom styles go here */".

You can specify delivery time when setting up your shipping options, and it will show in the store specially.
For other custom fields, could you make use of the "Product Filters" feature?
 

We can take a closer look at this option, but I can't make any promises right now. At the very least, I can say that it isn't yet on the roadmap.

I haven't reviewed the third party requirements recently, but there used to be prohibitions on interstitial pages for such things.

Just to touch on this in case anyone else comes across the topic - this will have absolutely negligible impact on performance, backups, storage consumption and so on as well.

This was indeed a warning for 3.X project. Well, time to update 

You didn't see spam posts - you looked in the database and found them. The very nature of allowing guests to post prior to registration can open up spammers to try to submit content, however unless they actually complete registration those posts are never displayed and will be appropriately pruned.
In other words, the topic here is a bit hyperbolic. 😉 There is no need to clean these posts up, the software will do it automatically.

You didn't see spam posts - you looked in the database and found them. The very nature of allowing guests to post prior to registration can open up spammers to try to submit content, however unless they actually complete registration those posts are never displayed and will be appropriately pruned.
In other words, the topic here is a bit hyperbolic. 😉 There is no need to clean these posts up, the software will do it automatically.

What makes you say there shouldn't be a range?
Some pages we may have to rebuild sidebar blocks because a cache has become out of date, and some pages we may be able to pull from cache. Some page loads we may have to update the session, while some page loads we may not. There are definitely going to be various factors that affect the page load time, and absent evidence of a specific issue, the statements here are a bit broad to act on. Hence why I recommended submitting a ticket.

All but one of those screenshots show a TTFB below 500ms, which is an acceptable range. The software does have to process things after all - we're not working with static HTML files where Apache can simply spit the file contents out to the browser.
The 600ms TTFB seems to be an outlier.
That said, ALL of these are below 1 second (1000ms), so the Theme.php code would not be relevant. The response would have to be longer than one second for the sleep call you highlighted to have possibly been hit.

max_input_time can be a limiting factor if the user's upload speed is very slow, or (again) it could be a limit set in your server software. I can't give you a blanket answer I'm afraid - there are plenty of causes.
If your user is at all technically inclined they may be able to open the developer tools in their browser when performing an upload to capture the actual response from the server. This will probably help identify what is causing an error.

The -200 error shows up generally when a PHP error we are unable to capture (such as "out of memory" or "max execution time exceeded") has occurred. PHP ends up exiting and printing out the core PHP error, and the uploader (which is a general open source uploader - we didn't write it) shows the "-200" error as a result.
@Mr 13 this can happen with large animated gifs when using ImageMagick but not GD simply because ImageMagick supports manipulating animated gifs (i.e. to create a thumbnail) and GD does not. Thus, what is probably happening is that ImageMagick is causing an "out of memory" error (manipulating large images is extremely memory intensive), while GD just skips trying to create a thumbnail altogether because it cannot retain animation.
We are happy to investigate if you submit a ticket, but 99% of the time the only real solution is to increase the resources available (remove memory limits, max execution times, etc. - sometimes there are limits in upstream software like Apache or nginx that need to be adjusted as well).

I've made a note for us to review this area of code for 4.5.

I've made a note for us to review this area of code for 4.5.