Posts by Byron Fitzgerald

    We had a server which updated their MySQL version to 8, which ended up breaking a few things on the site. It's a shop which uses variants, and the main issue was that users couldn't add products with variants.

    In MySQL 8 the way regexp work have changed and here is a brief outline one the changes that affect perch


    The Spencer library supports word-beginning and word-end boundary markers ([[:<:]] and [[:>:]] notation). ICU does not. For ICU, you can use \b to match word boundaries; double the backslash because MySQL interprets it as the escape character within strings.

    So if you are using perch shop or any regex filters in your collections or perch_content_custom functions then you'll need to update [[:<:]] and [[:>:]] to \\\\b.

    As you might not be locally developing on MySQL 8 what I did was replace [[:<:]] with a global BOUNDARY_START and [[:>:]] with BOUNDARY_END then in your local config you can set these to what you need without needing it go backwards and forwards

    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

    1. $post = perch_blog_custom([
    2. 'filter' => 'postSlug',
    3. 'match' => 'eq',
    4. 'template' => 'detail',
    5. 'value' => ($slug = perch_get('slug'))
    6. ], true);
    7. if (!$post) {
    8. PerchSystem::use_error_page();
    9. }
    10. echo $post;

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

    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

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

    1. UPDATE
    2. `perch3_content_items`
    3. SET
    4. `itemJSON` = replace(`itemJSON`, 'Original text', 'Replacement text')

    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

    1. <perch:if exists="vegetarian">
    2.     <td class="vegetarian">Vegetarian</td>
    3. </perch:if>

    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.