Posts by Byron Fitzgerald

    I did notice that on my test install but I thought it was because I updated a previous install. Collections are still there and work exactly the same as before. You'll have to enter the URL manually to get there though I assume now. If you try you should be able to get to them

    Going off of the download from I've gone through and checked what's been changed / added. So in lieu of any release notes here's what I've found

    Most of the changes seem to be auto formatting and consolidating standard perch with runway. Then there are some minor style changes which basically just change some borders and drop shadows.

    There is a new "Features option" for the sidebar menu, but as far as I can tell this is the same as a menu item, just a bit harder to find where to add them.

    There is a new collection index which you can't get to without entering the URL yourself. I assume the indexes are to provide better search results but I can't see anywhere where they are used apart from creating editing and deleting them in the admin area. Unfortunately I don't know what triggers the creation of the tables so they can't be made anyway, maybe a feature in the future.

    There are a few echo "heress" left in as well but apart from that, that's everything.

    Hopefully the download is incomplete and there is more to come, but who knows?

    If you open up your DB in phpmyadmin or another DB management tool, you should be able to execute the query.

    That count query is a check to see if the promotion code limit has been reached, so the issue is stemming from perch not being able to find/verify the promotion code.

    Whilst the SQL versions might be the same, the sql_mode could be different which could be making queries fail, though perch should log that in the debug. You can check this with the following query. Depending on your servers you might not be able to change this, but it might give you a bit more info

    1. SELECT @@GLOBAL.sql_mode;

    The check that happens before that line appears is

    1. if(strtoupper($data['discount_code'])!=strtoupper($code))

    Where $data is the cart info, and the $code is the Promotions discount code. Would be worth checking the promotion is set up correctly on the staging site, and then checking the result from the query is what you expect it to be.

    1. SELECT * FROM perch3_shop_promotions WHERE promoFrom<='2021-11-23 18:38:00' AND promoTo>'2021-11-23 18:38:00' AND promoActive=1 AND promoDeleted IS NULL ORDER BY promoOrder ASC

    I haven't used the v2 captcha in quite a while, but I think you need to use a callback for it to actually update the input value. You could try something like this (Untested though)

    1. <perch:input type="hidden" id="g-recaptcha-response" class="g-recaptcha-response"/>
    2. <div class="g-recaptcha" data-sitekey="YOUR_RECAPTCHA_SITE_KEY" data-callback="renderCallback"></div>
    3. <script>
    4. var renderCallback = function(response) {
    5. var $response = document.querySelector('.g-recaptcha-response');
    6. $response.value = response;
    7. }
    8. </script>

    The first error is caused as perch can't find a template for the collection. Check if the collection key is correct and that it has a collectionTemplate set in the DB for the collection. If both are correct you can pass through the template as an option which should fix the notice.

    As it doesn't look like the template is found I imagine that the rest of the process of fetching the data isn't working. Are there any errors in the perch debug?

    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>