Posts by hus_hmd

    One of Perch's main selling points is to allow developers create bespoke websites with ease. While Snipcart allows you to easily add a cart to your site, you do give up some control.

    I don't think a first-party e-commerce add-on is a bad idea. And while I agree that more examples would help developer (as Clive Walker said), I also think some developers in the Perch community generally underestimate what's required to build an e-commerce site with Perch Shop and end up being frustrated as a result. Familiarity with Perch as well as a good understanding of PHP would've made a big difference in those experiences.

    Perch has always given developers a blank canvas more or less. And Perch Shop is no different. It is not a magic solution. You'd still need to understand how to implement and work with:

    • User authentication with Perch Members, account area, basic member forms such as profile and password reset, password reset flow including emails
    • Perch-templated forms
    • HTML forms and what happens when something is submitted
    • How PHP handles form submissions
    • a list/detail pattern (that actually handles 404 for unmatched items; Perch never did this for you)
    • user-filtered lists (forms/links often with dynamic values e.g. categories, and requires understanding filtering in Perch)
    • being able to debug PHP issues
    • and the list goes on...

    I think Perch Shop feels incomplete and lacks in various areas, but I feel people point a lot of blame towards it (and Drew/Rachael) even when they may not have the required skillset to build an e-commerce shop with Perch Shop in the way they envisioned.

    It is possible that Perch here excepts all the files to be directly in tempaltes/pages/attributes/. I think the next logical step would be to try to remove the sub-directories and see whether the issue persists:

    • tempaltes/pages/attributes/some_file.html
    • tempaltes/pages/attributes/another_file.html
    • etc.

    Creating well-thought-out region that uses blocks seems to be the answer for me.

    The default master page for most of marketing sites I build on Runway nowadays is literally just this:

    1. perch_layout('');
    2. perch_content_create('Blocks', ['template' => 'blocks.html']);
    3. perch_content('Blocks');
    4. perch_layout('global.bottom');

    You can enforce design rules and follow brand guidelines. And you're not restricted to content templates. For instance, you can create a "global" block that allows the editor to select a global section (e.g. featured products, latest blog posts, forms, etc):

    So I feel what you're asking for is already addressed by Blocks (at least for the most part). If it falls short in some areas, perhaps it is better to explore those areas first.

    (maybe even have a code ide built-in

    Perhaps a textarea field with a lightweight code editor can be helpful. For example, you may set up a shared region for editors to insert analytics tags like Google Analytics. Or perhaps you have a blog and would like to add custom CSS to style some posts differently.

    One of the reason I hated maintaining WordPress sites I inherited was how some of them would have HTML and inlined CSS code inserted via the control panel. I want a CMS to manage content, not code. I want to version control source code and I think storing source code in the database would cause more issues than it solves particularly for client sites.

    When consulted on e-commerce approaches on Perch project over the last 1-2 years, I always suggested Snipcart as an option. Besides the lower debt tech and the resources of those who consulted me, Snipcart's Stripe integration is up to date.


    It would be nice to implement into Perch as an app

    Given Runway collections can be used to create the products, what would a Perch app provide in this case? Provide a way to add products via the API instead of just the HTML? Or are you thinking about listing/managing orders/inventory/etc on the Perch control panel?

    Thank you ryan for open-sourcing Chirp and making it available for the community.

    If I remember correctly, you had some sort of roadmap on Trello. Perhaps it would be useful to add these as issues on GitHub?

    I had seen that in the docs. Does anyone know if this method will reduce the size of an existing table? Or only prevent a new build table getting large?

    It will reduce the size of an existing index table, but you'll have to resave the regions multiple times for Perch to clear the old records from the database. Given you're dealing with content regions, republishing the pages (there is a Republish button on the pages list control panel page) may reindex all content regions.

    Hi Mat,

    Since a block can be added multiple times, a template-only solution may not prevent cases when an editor uses the same block more than once. The each callback option can be useful here:

    In your template you can output block_field:

    1. <perch:content id="block_field" type="hidden">

    Hi Loudon,

    Given customers buy products (not categories), I'm not sure this is doable. What is your goal here? Do you want to output the product's category in a notification email?

    -- /perch/phpinfo.php

    -- /perch/resources/phpinfo.php

    Perch does not ship with these files as Clive Walker mentioned.

    I'm not sure what they mean by "response headers".

    You can check the response header with your browser's DevTools. You can learn more about them:…/Glossary/Response_header

    X-Powered-By is a common non-standard HTTP header that some servers send along with their response headers. The header often provides information on the type server and in your case the version of PHP installed. Disable this header (and review the other headers the server sends) or ask your web host to do so.