Posts by Byron Fitzgerald

Very strange that they are blocking outgoing SMTP, never heard of a hosting company doing that before.

The perch mailer class uses PHPMailer under the hood so you can rely on that to deliver emails, but without SMTP it can be 50/50 whether the email will be delivered without it being marked as spam.

If you wanted to go with Sendgrid you'd need to update the PerchEmail class (/admin/core/lib/PerchEmail.class.php), however as your editing a core file support would be invalidated and when/if perch release another update it could cause other issues down the line.

Otherwise the only other options I see is getting them to switch on SMTP for you, or moving to another host again.

You'll want this to be at the top of your page, as the use_error_page function is basically just an convoluted includes function that sets the HTTP status to 404 as well

It might be that you are using includes instead of perch_layout that it's including the header/footer again

What about your post page?

I think with the way perch is designed it's probably best for it to not be default behavior as Perch tends to be a very much DIY but here's some tools for you. Features like this make it a bit more opinionated, as it keeps in line with most perch_x_custom functions.

The routed 404 page is also a Runaway only feature, and as blog is a standalone addon I think it makes sense to not do this by default, though an option to pass into the perch_blog_post function to enable it would be nice

What does you master page template look like?

You need to trigger the error page for this to work. I think something like below would work

I believe the pageModified field is only available when using perch_pages_navigation()

You'll want the perch3_content_items table so your query will look something like

It's worth noting that the field ID's are also stored in the itemJSON, so if the text you're replacing contains and ID of one of you're fields it will also overwrite that.

You can add a suppress attribute to the tag and stick it at the top of the page, something like

So from your SQL query it looks like what you are doing is updating the cached HTML, which is why it shows correctly on the front end. In the admin site, perch ignores this so it will be showing the old content.

I think you should be looking to update the itemJSON field in perch3_content_items. Then resaving will update the content_index as well as create the cached HTML for you

A checkboxes default value is one, if you want it to be different you need to add it to the tags

<content id="vegetarian" type="checkbox" value="Vegetarian" label="Vegetarian">

But you probably don't need to even output the value as you are already using a perch:if check

What does you SQL script look like? It might not be changing all the necessary fields

We've used the https://github.com/RootStudio/Perch-Locator app on a few recent sites and is still working fine up to PHP 7.4. It hasn't been tested with PHP8 yet.

It does rely on the perch scheduled tasks to geocode the locations so you'll need to either set the cron up for that or visit the scheduled tasks link manually if you are developing locally.

That's strange, I've never had this issue before. Are your apps loading any extra JS? Anything popping up in the console?

Quote from JayW

That sounds like uncommon user error.

SKU's are widely understood as needing to be unique, it's the whole point. Entering "GRE" for both green and grey sounds like someone needs to type "what is an SKU" into Google! We need less distractions towards V4, not more!

Whilst it may be user error, one of the reasons we use validation is to prevent user error. If you are managing a large shop with lots of variations it's not unreasonable for someone to add a duplicate SKU and the CMS should provide feedback on that. The SKU is a unique field but it is not enforced, which to me sounds like something the CMS should handle, or at least notify you

You could say duplicate slugs are down to user error, but most CMS tell you when you have a duplicate slug.

If that's the case the issue is unlikely to be due to perch translations and more likely a locale issue with the date field type. The date picker field type utilises strftime to get a list of months, this relies on the locale set.

You could try using setlocale() to update the locale english which should then show all the months correctly. If the rest of the site is also in English it would make sense as well to do so.

Looks like there is a typo in you perch:if at match="eg", should be match="eq"

It would probably be worth doing a global search through your files and looking for any references of the months, which should hopefully show you which files the translations are in

You should be able to find the translation files in your perch/core/lang/ folder. Each addon will also have it's own lang files which you can find in perch/addons/addon_name/lang/

I'd love to trial V4, how do you plan on distributing it/?