Posts by hus_hmd

    Hi James,


    While the skip-template option returns the items' data, it does not include all the raw data by default. You can tell Perch you want all the raw data with the raw option:


    PHP
    1. $articles = perch_blog_custom([
    2. 'count' => 3,
    3. 'sort' => 'postDateTime',
    4. 'sort-order' => 'DESC',
    5. 'skip-template' => true,
    6. 'raw' => true,
    7. ]);


    Hopefully this will return all the image data you need for templating.

    You have some custom properties in the memberProperties column:


    Code
    1. {"first_name":"AAA","last_name":"BBB"}


    Does any of the records you imported has an empty value in that JSON? e.g.


    Code
    1. {"first_name":"","last_name":"BBB"}


    Or does any have a missing property? e.g.


    Code
    1. {"last_name":"BBB"}

    What sort of data did you add to the database table? Just the default columns? Or did you add some custom properties as JSON in the memberProperties column? It would probably be helpful if you shared a sample of the data you entered.

    You can build a Perch app and register a scheduled task so it periodically fetches the data you need.


    Depending on your requirements you may choose to store the data in the database or even just save it in a parse-able format like JSON in a file. I'd consider the amount of data, how long you need to keep the data and whether you need to paginate and filter it.

    Adding perch:content within a perch:input can cause problems when Perch parses the tags during validation, so make sure it is the last thing you add and after all other attributes:

    HTML
    1. <perch:input id="p1Finish" type="select" options="<perch:content id="finishOpt" type="text" label="Options List" />" />


    Plus I wasn't aware you're only dynamically adding values (and not dynamically adding perch:input tags). In this case, perch_content_custom() or perch_form() should also work like Byron Fitzgerald suggested. Though I'm not sure whether the name attribute is required.

    The file-type attribute filters existing assets in the asset chooser. I think the editor can still upload PDF files.


    It's not ideal that Perch allows selecting PDFs in an image field. One option could be to add a conditional to not render the PDF files at all so the user is forced to pick an image instead:


    HTML
    1. <perch:if id="image" match="!contains" value=".pdf">
    2. <img src="<perch:content id="image" type="image" label="Image">" alt="">
    3. </perch:if>


    The above doesn't really cover all cases because it will also match any file path of an image that contains .pdf like /perch/resources/my.pdf_elephant.jpg.

    Upon submission, Perch checks the submitted data against the form fields in the form template. Perch does this to validate the form.


    So when you add dynamic fields at runtime (on page load), these dynamic fields are not accessible to Perch for validation. As a result, they are ignored. It doesn't matter what function you use to render the form here.


    What works is having your form and your dynamic options in a content region, and outputting the form with perch_content(). This works because the dynamic options are rendered and cached when you save the region. To elaborate, when you save the content region Perch renders perch:content tags, but does not render the Perch form tags (these are rendered at runtime). So the cached contents of your region should contain your Perch form tags, which Perch can access upon form submission.

    I am fairly sure that I successfully added PDF assets for which Perch did not generate thumbnails.


    Does the issue happen when you upload any PDF? Or are you only testing with the same PDF?


    And where does this happen? In a content region?

    Yes, there is. You can use $_POST or the perch_post() function:


    PHP
    1. // check if a Perch-templated form has been submitted
    2. if(perch_post('cms-form')) {
    3.   // set variable from the posted value
    4. PerchSystem::set_var('firstname', perch_post('firstname'));
    5. }
    6. perch_form('my_form.html');

    Hi Charlie,


    You can use Perch Members to restrict access to content on the site.


    The payment solution can be anything. You can always integrate something like Stripe without using Perch Shop so you don't have to deal with Perch Shop's current issues. If this requires a recurring payment solution, Perch Shop is not an option anyway.

    I tested in Chrome as I thought that could be the case and I received a similar error message but referencing JSON. I can dig this out if it helps?


    This is probably the issue. Unsure why exactly it is not working for you as I have used this on multiple sites without an issue. I'll look into it and report back.

    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:


    PHP
    1. perch_layout('global.top');
    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): https://grabapipit.com/blog/a-global-block


    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.