Posts by justanotherdave

    You would be better off either moving to a different platform, or patching the last version Drew put out to php 8.1 yourself. I'm in a similar situation. I only have 1 website which uses Perch Shop and at the moment it's running on PHP 7.4 and is fine. I'm sure the day will come though where my hosting company insists I'm using PHP8, and at that point I will probably have to look to employ a PHP developer to patch the software for me.

    As for other software similar to Perch and Perch Shop, the nearest I've found is Craft CMS with Craft Commerce. It's expensive though, but I guess as we have all learned - you get what you pay for.

    I've tracked the issue down and fixed it. If anyone else runs into this: The member that was created from the previous order was still logged in when placing the second order. And even if I entered different details in the checkout, if the email address was the same it would link that order to the logged in user and use that name and address. Strangely, it does actually create a new member, even though you're logged in. It just doesn't use their details for the order.

    I thought this was to do with multiple members with the same email address being created, as it was a full day between me placing the first and second order. But I must have still been logged in as the first member.

    The way I've "fixed" this is to add perch_member_log_out(); at the top of my checkout form. So a user isn't able to checkout while still being logged in from a previous session.

    I still have the issue with multiple members all with the same email addresses. But as I'm not having a members area I guess it isn't an issue for me. It just seems strange to allow it in the first place.

    Hello Everyone :) I'm hoping someone can help me with a Perch Shop issue.

    I have created a password less checkout on my Perch Shop following the examples in the documentation. All works fine, I go through the checkout process and a member and order is created as expected. The issue I have is if a second order is placed. If I use the same email address at checkout a new member is created with the same email address but a different member ID. Then in the order details in Shop, it's pulling through the member details from the first order with that email address rather than the details that were entered during checkout for that order. So the end result it's it's showing the wrong address.

    I do have the PerchMembers_Members::check_email helper on the email field during checkout, but it doesn't stop multiple members with the same email address from being created. Is it supposed to? The password field is also there and set to hidden with a value of __auto__

    Ideally how I would like it to work is if the same email address is used during checkout, it just updates the details for that member, without them having to enter a password.

    I've attached my checkout template below. Can anyone see anything wrong with it?

    Thank you :)

    Scrap that it's stopped working again. Worked this morning. Came back this afternoon and nothing. Ugh ;(


    Ok I think I've finally found the issue. If I use a private browsing window (Safari) the promo codes work fine, and if I go into Safari settings and clear all website data then back to the shop and use a code it works!.. Which has me stumped to be honest. Are form submits effected at all by things like cookies? Does Perch store any data in the browser that would effect the promo codes?

    I'm not sure why it worked earlier now, unless changing the PHP version and creating a new promo code had some effect on something stored by the browser when revisiting the site. Again why I didn't run into this issue on the local copy of the site using the same browser I don't know. Honestly feel like binning the whole thing right now. It's always the last 1% of a site which ends up being the most time consuming!

    I seem to have solved it. It is to do with PHP versions. If I drop the PHP version down to 7.3 on the server and create a new promo code, that will work, even if I then bump it up to 7.4 afterwards. But if I edit or create a promo code on 7.4 that breaks it, even if I drop down to 7.3 after it's still broken until I delete it and create a new one. So it's something at the point of creating or editing a promo code on 7.4.25 specifically that doesn't work. 7.4.21 on my local server works fine, but I only have 7.4.25 on my staging server or 7.3.32.

    I don't know if anyone else is running shop on 7.4.25 and can test to confirm that?

    The warnings and other errors to do with tax and the money format are all gone on 7.3 as well. I guess Shop just doesn't work on 7.4, which isn't great.

    Once the site is done I will update Perch 3.2 and see if that makes any difference. I'm hesitant to do that at the moment though as from what I gather it was a rushed update by the new developers to silence some of the complaints on the forum.

    Yes, I think you're correct as if I enter some code which doesn't exist on the local site I get the same debug messages as I get on the staging site when I enter a code that does exist. I will have a look at the database in phpmyadmin as you suggest.

    Another thing I've just noticed in the debug on the the cart page after entering the discount code and submitting the form there's this right at the bottom of the page. This appears on the staging site but not on my local site.

    1. Array
    2. (
    3. [type] => 8
    4. [message] => Trying to access array offset on value of type bool
    5. [file] => /public_html/perch/addons/apps/perch_shop/lib/PerchShop_Cart.class.php
    6. [line] => 662
    7. )

    I've looked in that file at line 662 and it seems to be something to do with tax. Which again I don't get this on the local copy. Do you know what it's trying to do here?

    Thanks for your help :)

    I'm 99% the way there to finishing a decently sized Perch Shop project, with blog, custom posts and a few other things as well. It was a pretty big project for me which I've been working on part-time for well over a year. Now its looking more and more likely I'm going to have to port the entire thing over to another platform when PHP 7.4 becomes end-of-life.

    What a nightmare.

    Thanks Byron.

    I'm almost certain that the discount code is set up correctly, as I have the exact same site on my local server and that works as you would expect. How would I go about checking the result from the query?

    On my local site between the SELECT * FROM query and the Promo skipped (or in the local sites case Promo qualifies) there's another query:

    1. SELECT COUNT(*) FROM perch3_shop_order_promotions WHERE promoID=1

    Which doesn't appear at all on the staging site. I assume this is just because it's not picking up any promo code to apply? If that's the case I'm pretty sure the issue is that on the staging site it's not matching the promo code entered with the promo code stored in the database for some reason.

    I've got the staging and local sites side by side and I have noticed a warning on the staging site in the admin panel under shop, which doesn't appear on the local site:

    1. Deprecated
    2. : Function money_format() is deprecated in
    3. /public_html/perch/core/lib/PerchTemplate.class.php
    4. on line
    5. 1664

    Both sites are running Perch 3.1.7. local is running PHP 7.4.21 and staging is 7.4.25. Is that likely to be an issue do you think? That small PHP version change causes the deprecated warning above? If I drop the PHP on the staging site down to 7.3 the deprecated warning in the admin panel goes away but the discount codes still don't work.

    The MySQL on local is 5.7.34 and staging is 5.7.32-35 but I don't think I can change the MySQL version anyway.

    Also on the staging site under the shop tab it shows Revenue and Recent orders where's on the local it only shows Recent orders which is strange as both these sites are the same. I literally copied all the files and the database from my local server and uploaded them to a staging server yesterday.

    Thanks again for the reply.

    Hi guys, I'm hoping someone here can help me.

    I have a Perch Shop install where I've created some promo codes. All work fine on my local version. When I upload the site to a staging area and copy over the database the promo codes no longer work. The environments are the same as far as I know and everything else works fine.

    I've turned the Perch debug on, and when saving a promo code in the admin panel on the staging site, it saves and the database is updated, but I get a red perf bad debug message:

    1. SELECT mi.*, p.privKey FROM perch3_menu_items mi LEFT JOIN perch3_user_privileges p ON mi.privID=p.privID WHERE mi.itemActive=1 AND mi.parentID=0 ORDER BY itemOrder ASC LIMIT 0, 1

    On my local install when saving a promo code this isn't red. It is yellow (warning) though. It's the only difference between the two copies I can find and I suspect it's what's stopping the codes from working. Does anyone know what this means?

    When actually entering the promo code in the basket I don't get any errors, it just doesn't apply it. In the debug on that page after submitting the promo code I get:

    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

    In the debug. Which should match the promo code saved in the database, and does on my local copy. But on my staging site I just get:

    1. Promo (£10) skipped: discount code not applied.

    Directly after it.

    If anyone could point me in the right direction that would be a great help. I've really no clue what's going on. ||

    Hi Byron. I just followed the instructions here: for the V2 installation so the only Javascript I've added to the page for the reCapatcha is <script src="" defer></script> which brings in…uYJ_3zSP/recaptcha__en.js in the head of the page.

    Like I say the reCapatcha works as far as if you don't complete it the message goes to spam and if you do it doesn't and it gets sent. But there's no warning about not filling it in, if a user just ignores it and submits the form as far as they know the message has been sent, where's in reality it's been flagged as spam.

    The g-recaptcha-response element which is supposed to be filled in when the captcha is completed never gets filled in as the ID isn't called g-recaptcha-response as Perch changes it to form1_g-recaptcha-response. I tested this by making this input a normal input not a perch:input and it then got completed when the captcha was completed. But of course it doesn't work as Perch doesn't know it exists and so the Perch honeypot field is never filled in and the form submits and and email is sent even if the captcha isn't completed.

    I've tried before to get the form1_ bit removed somehow while still keeping it a perch:input but can't figure out a way to do it.

    Unless there's something else I'm missing and the ID being changed has nothing to do with it. This is the page it's on:

    I've done this with Javascript before. All I did was add a data element to each search result item to identify which type it was, eg: data-filter="shop". In my case it was so that I could filter a site-wide search and display either blog posts, articles, products or everything. I'm not sure this was the best approach but it works and I'm more comfortable with javascript than PHP so it was my go-to solution. You could do something similar to filter by date as well.

    I've used the google Recaptcha plugin and while it does work it's not a perfect implementation. The main issue I have with it is the input ID g-recaptcha-response is changed to form1_g-recaptcha-response by Perch. What this means is there's no user feedback to tell a genuine user that they need to complete the recaptcha. I also have warning in my Google dashboard saying that the recaptcha isn't implemented properly, I assume this is caused by the same issue.

    Does anyone know why Perch changes the IDs on forms? I thought maybe it was to identify which forms are which, but even when I have more than one form set up they're all have form1_ added to the IDs. I suppose if there's more than one form on a page? I don't think I've ever tried that.

    Hi Perchers. Quick question.

    Is it possible to use the perch:success and perch:error form tags in the Perch Shop cart? I need to give some feedback in the cart for when a user enters a discount code. At the moment it just either applies the discount, or doesn't. I tried using the standard success tag which work, but then don't display the rest of the form when the cart is updated, just the success message. And I also didn't know what type= to give the error tag for the discount code input, so that doesn't work at all.

    If the success and error tags aren't going to work. How would you go about giving feedback on cart actions? I suppose I could do it by checking if the amount in <perch:shop id="total_discounts_formatted"> has changed. Or is there something better?

    Thanks :)

    I know this is old but I just ran into this myself so I might as give a solution for anyone else that finds this post. When setting up the discount code for a fixed amount, you also need to enter the same amount in the maximum discount box as well.

    I'm sure they are working on an updated version, and yes the company that now manages Perch might be bigger, but that doesn't mean Perch is their only project. From what I gather it's actually a very small company with remote workers - like many software companies are these days. I suspect they might have 1 or 2 developers at the most working on Perch, and I doubt full-time. So in reality no more work is being done than before it was sold, but now the developers aren't the ones who built the software so progress is going to be a lot slower.

    I've been using Craft CMS for my recent projects and it's very good. Expensive, but if that means it's not going to be forgotten about then that's fine. I still have sites on Perch and I'm not going to replatform them unless they break down completely. But for now I won't be using Perch for any new sites, not until the future of the project becomes a little clearer.

    We all know this isn't going to happen. At this point it's pretty obvious that they've taken more on than they can handle. They're either unable or unwilling to invest the time and money needed to create a viable product, and in the meantime what little users they had left are jumping ship, and I don't blame them.

    It's a shame as I'm sure this isn't what Drew and Rachel wanted Perch to become when they sold it.

    Did you go ahead with this? Which apps aren't PHP8 compatible at the moment?, do you know? We do have until November 2022 until PHP 7.4 becomes unsupported. I've recently developed a Perch site which uses Shop, Blog, Members, Forms and all seems well on PHP 7.4 running Perch 3.1.7.

    I'm hoping I can keep things running smoothly on 7.4 until either Perch is updated or I move all my sites over to Craft CMS. At least I've got a year to decide.