Posts by hus_hmd

    Hey Brad,

    The rendered HTML should include the token value. I think you also need to assign the token value on the input tag (apologies as I don't think the docs specify this). Since you're using perch_template(), you need to use the perch:content namespace.

    1. <perch:input type="hidden" id="token" value="<perch:content id="token">">

    You're also passing the member ID, but not using it within the form 'member' => perch_member_get('id'),. If you have a field in the collection to record the member, you also need to pass the ID at the moment. More details on this is in the docs.

    If you want to see Perch form errors in the debug message:

    1. // all forms on the page
    2. PerchUtil::debug($Perch->form_errors);
    3. // specific form
    4. PerchUtil::debug($Perch->get_form_errors($formID));

    And I am wondering what you personally think about the event app.

    I think I started using Perch when the Events app was already considered old and no longer supported. I never used it myself on any project. Regions or Collections did the job just fine for me.

    I'm unsure if it makes use of Perch's relatively newer features as things stand, and I doubt it would be updated to support any new core features.

    How would you add a two level filter there? With a user-filtered list? Users should be able to filter and/or type and date of events.

    There is no one way. If I remember correctly, the archive page that comes with the Blog page includes examples of filtering by dates. The type of the event can be a custom field or a category field (filtering by either one is different).

    A quick example:

    As the documentation of the template filter states, it is for images. You can use serve videos via Cloudinary, but the current implementation of the template filter doesn't handle that.

    The template filter is open source if you need a starting point to build your own (or fork it and submit a PR). If your use case is very simple, you can even hardcode the Cloudinary URL in the template instead of using a template filter.

    In any case, serving videos via Cloudinary would probably use all your monthly bandwidth in the free plan very quickly.


    Developer-focused wish list:

    Multiple form validators
    See: Multiple form validators - Add-on Ideas and Requests - Perch CMS

    Stricter server-side validation for required fields

    See: SubmittedForm: stricter validation for required fields - Add-on Ideas and Requests - Perch CMS

    PerchAPI_SubmittedForm - validating values in arrays

    See: SubmittedForm validating arrays - Add-on Ideas and Requests - Perch CMS

    Custom tag attributes on Perch-templated forms

    See: Custom attributes on Perch form tags - Add-on Ideas and Requests - Perch CMS

    Multiple apps processing form submissions

    It is currently possible to process form submissions with multiple apps like so:

    1. <perch:form app="perch_forms custom_app1 custom_app2" ..>

    However, this means all apps process the submission. It would be nice to be able to restrict this so an app can only process the form if the previous app doesn't throw any error. e.g. This would allow developers to handle spam in this way:

    1. <perch:form id="register" app="spam_handling_app perch_members" ..>

    PerchAPI_ContentImporter: ability to locate and update existing items

    Having built Perch apps that sync data from 3rd-party systems, I always needed to extend the PerchAPI_ContentImporter class to add functions like find_items(), update_item() and delete_item().

    See: PerchAPI_ContentImporter: locate and update item - Add-on Ideas and Requests - Perch CMS

    PerchAPI_ContentImporter: ability to import into and update/delete repeater fields

    This is not possible in v3 and there are many use cases for this. e.g. importing an item from a third-party source with multiple images.

    Non-Latin characters in page paths and slugs in general

    See: Non-latin characters in page paths and slugs - General Discussions - Perch CMS

    Built-in localisation support

    In some parts of the world, even if you only target local audience, websites are expected to be available in multiple languages. So built-in localisation support can make Perch a reasonable solution to many developers.

    Better way to manage Collection item URL

    In the template and in PHP

    See: Collection item URL - General Discussions - Perch CMS

    Collections to support larger data sets without performance degradation

    In v3, Collections are flexible but they cannot really handle large data sets. This is especially true if you have a lot of revisions stored in the database and many index-able fields.

    The best approach I found so far is to build custom apps that stores data in its own database tables. I get a much much better performance this way. I've been in projects where database queries literally took seconds to complete with Collections, and the equivalent in a custom app would only take milliseconds.

    In return, I lose some collection features like relationships so I end up creating a custom field type. And when I look back at these projects I find that I have created a maintenance burden for me or for whoever is responsible for maintaining that project. I also lose the flexibility of easily adding new index-able fields via the template as I may now need to add new columns in the database instead.

    Building a custom app also costs more money and takes more time. And so does migrating data from existing Collections to the new database tables. It is not a fun explaining this to end clients who you convinced to use Runway over other options.

    So I'm looking forward to see a significant improvement in this area. I'd love to see better performance with larger data sets, as well as clear growth path(s) in case that is not enough for some use cases (i.e. it would be extremely helpful to also have the limitations documented so developers can evaluate things better and plan ahead to manage potential outgrown data sets before it is too late. Hopefully some approaches on how to handle the very large data set would also be documented.)

    See this thread for more in-depth discussion: Collections / Elasticsearch / custom app - General Discussions - Perch CMS

    Setting up page routing outside of the control panel

    It may be wise to keep the ability to manage routing from within the control panel, but I feel like it would be make life a lot easier for developers if they can also manage this from their code editor.

    This is the kind of thing I don't necessarily want stored in the database. I realise this make it challenging because someone might make some changes to the routes on the live site and these changes would not automatically get reflected on the developer's version-controlled codebase.

    See: Staying out of the control panel - General Discussions - Perch CMS

    Configuring collections outside of the control panel

    Similar to the above point, I think it makes sense to make it possible to configure Collections outside of the control panel. This is for a number of reasons.

    (1) Better developer experience! I do not enjoy reconfiguring similar Collections via the control panel on every project. For existing projects a developer may need to manually configure new collections on multiple environments too (dev, staging, production). I much rather these configurations are managed via the codebase where there are managed in a single place.

    (2) As Collections are becoming more powerful (especially if they are able to handle large sets of data without affecting performance), there is less need for (first or third party) custom apps that basically just manage content repositories (blog, events, real estate listings, etc.). Setting up Collections and Categories alone can replace the need for many custom apps. We'd still need custom apps for other things (e.g. ecommerce, developer-utilities, etc.)

    Developers then can share templates/configurations for Collections instead of building and maintaining apps. Think about crazy-flexible products like and Airtable where there are pre-configured templates. Templates in such products are often configurable and extensible.

    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:

    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:

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

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

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

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

    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:

    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:

    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:

    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');