Perch V4 (and future) Megathread

  • Agree on not using 'Likes', in-fact, I personally think you should disable the ability to like a comment entirely. It just adds noise to the forum without any meaningful contribution. I'm not opposed to voting on features but it should be done in a place where you layout a possible roadmap and get users to vote there.


    Perch previously did this by using Trello for Shop features, but unfortunately development was so slow it was a pointless exercise. But something similar might be worth considering, or even just using GitHub issues.


    Another thing that came up in the past was the reluctance to look at what other CMS's or platforms were doing. When users would post to the forum that CMS X does Y, the response was usually "we don't have access to that and don't intend to look" so we'll do it our way. This is a bit shortsighted, especially when that particular feature might have already been solved in the best way. How the developers of a CMS wouldn't have local installs of all their competitors is beyond me.

  • I think the biggest ‘feature’ will be the potential switch in licensing model. If we do go to the proposed yearly model (which to be fair is now pretty much the norm), I think existing licenses should be grandfathered in.


    This way we don’t have to have the conversation with clients, and we have the updates for life we were promised at the time of the purchase.


    Any new licenses can be what they need to be and can be accommodated for in proposals. I don’t want the yearly subscription but if it means the continuation of Perch so be it.

  • Hello!!


    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:

    HTML
    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:

    HTML
    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 Monday.com and Airtable where there are pre-configured templates. Templates in such products are often configurable and extensible.

  • Preach!!

    +1 Please don't make Perch anything like Wordpress! I came to Perch because it wasn't like Wordpress (as I would think a lot of people here did).


    I like how Perch isn't bloated. I don't think add-ons need to be part of core either. If you don't have a blog on your site you don't need the blog files cluttering up your project for example.


    Off the top of my head, some improvements I think would be good in the future:

    • Ability to have repeaters within repeaters.
    • Google reCaptcha support much like the mbk addon for Perch Forms (which I don't think is in development any longer).
    • Disable caching when Perch is in development mode. It used to work, but in later versions of PHP I still need to resave a region for changes to a template to take effect even when PERCH_PRODUCTION_MODE is set to PERCH_DEVELOPMENT.

    Thanks for all the updates recently! Very much appreciated.

  • Perch previously did this by using Trello for Shop features, but unfortunately development was so slow it was a pointless exercise. But something similar might be worth considering, or even just using GitHub issues.

    Agreed. The shop roadmap is still up. A clearer idea of what features are being added would really help generate more enthusiasm. Being asked to make suggestions here is very welcome, but it's good to know that suggestions will be acted upon.

  • Hi everyone,


    Thank you for the continued support and activity here!


    Just as a quick update for you, all items up to my previous comment have been raised in our Perch meeting. We're currently working on a full delivery timeline for these items, and we'll share further updates as we have them, though rest assured our release for V4 by the end of June is still on track. I'll be continuing to pass your suggestions and requests onto the team.


    Thanks again!

    Gareth

  • *starts pasting Perch regions into current site*

  • A small improvement but fixing the lack of support for <perch:help> tags within blog posts would be helpful for less tech savvy end clients. Notes before works but isn’t the same if you have to literally give them a step-by-step how-to… would certainly save a few phone calls/emails!

  • Hi Everyone,


    Firstly, I've noted down all of your suggestions and requests for discussion in the next meeting. Following on from our last meeting we're hopeful for an interim release before V4, so the specifics are still subject to change. However, of the bigger items which are set for V4, the work to update the baseline for the code to PHP7, and the simplification of Perch vs Perch Runway features are on track. Aside from those, another item that is still in the works is to add the ability for collections to be indexed, in short this means if your site is starting to hit performance problems and a collection is becoming slow, you can create a custom index.


    As always as soon as we have more details to share we will, and thank you again for your continued support.



    Kind regards,

    Gareth

  • New ‘add CSS class to perch field’ attribute

    I suggest adding an extra perch attribute (for example “perch-css-class”)
    which will add a class to a perch field in the Perch Admin software.
    The class will not be part of the front end website, only will be added on the Perch edit pages.


    With this added class, I can then add custom CSS in perch/addons/plugins/ui/_config.inc to change the way this field is shown in Perch.


    Maybe combine it with this suggestion about the forms app fields: Custom attributes on Perch:forms


    Code example.

    Code
    1. <perch:content
    2. id="contactName" type="text" label="Contact Name"
    3. perch-css-class="myClassName"
    4. >