Posts by hus_hmd


    The site did use Tinymce but I understand this will not work now.

    You can install additional editors ( TinyMCE is listed in the add-ons archive. Not sure whether it works on Perch v3 though.

    I have tried the others and none of them let the user update tables that I can see.

    Perch v3 ships with Redactor. You can install the Redactor table plugin.

    Helpful resources:


    I believe this is a bug.

    Since you are already on Runway, I think using Collections for your different blogs is probably the best solution at this stage.

    Hi Graham,

    You can create the new Collection via the control panel, then use the import API to fetch all the items from the old Collection and add them to the new Collection.

    Out of curiosity, what is the reason for not editing the original collection directly without duplicating it?

    If you don’t actually have to pay yearly and the vast majority of people don’t seem to actually update regularly what incentive do they have to fork out the extra to update?

    I don't know whether the vast majority don't update regularly. What we see on the forum could be a small number of Perch customers.

    Also even the developers that care about keeping Perch up to date for their clients are likely not to regularly update it for all clients if they are not paid to maintain the site. So if freelancers/agencies only update Perch when they are paid to do so (e.g. maintenance as part of a retainer), they can take the updates cost into account when pricing their services.

    If a developer/agency does not get paid to maintain Perch sites (and hence don't need the updates), then the proposed license only affect them in the way that they cannot re-use the same license (with the latest version) over and over again.

    I would bet it wouldn’t make a huge increase in revenues.

    Since the proposed model would prevent someone from re-using the same license for a new project every x years for free (assuming they want the latest version whenever they start a new project), customers may potentially pay to get updates for an old license to avoid paying the full price for a new license.

    So we may see:

    • customers paying for new licenses
    • customers paying for updates because their clients pay them to maintain the site
    • customers paying for updates because they want to re-use licenses (with latest version) on new projects

    That would be better than what's happening right now. Whether that would meet their goals in terms of revenue is for Drew/Rachel to study. If they ultimately decide to keep updates free, then at the very least they can do something to prevent the free reassignment of older licenses like ex-jedi suggested.


    A good way to debug this is to output the array so you can examine it:

    1. echo '<pre>' . print_r($bookeddates, 1) . '</pre>';

    Or if you have debug mode turned on, you can output the array in the debug message at the bottom of the page:

    1. PerchUtil::debug($bookeddates);

    Since this is a multiple-item region, your array probably looks something like this:

    You can filter the array in PHP, but you can also filter the region items directly:

    1. $result = perch_content_custom('Wedding Dates', array(
    2. 'skip-template' => true,
    3. 'filter' => 'your_date_field_id',
    4. 'match' => 'eq',
    5. 'value' => $date,
    6. ));

    I personally think it would be a reasonable change. It is not a model where you have to pay to keep using the software. You can use the software forever. You just don't get free updates forever. There are a number of software companies that started using a similar pricing model including Sketch and Craft CMS.

    Based on what I read on the forum, many don't update Perch regularly. If it wasn't for PHP 7, many would still be running versions that predates v2.8.34. So the proposed license model may not even affect all customers.

    I understand that some customers who run agencies may have a very large number of licenses so paying for updates per license may be a big turn off. Perhaps additional options could be provided:

    • (A) Pay updates per license (suitable for those who have a small number of licenses and/or those that do not need to get updates for all licenses). You don't have to pay if you don't want the updates.
    • (B) Pay a single fixed subscription fee to get standard Perch updates for all the licenses in your account. Use (A) for your Runway licenses.
    • (C) Pay a single fixed subscription fee to get standard Perch and Runway updates for all licenses in your account.

    This way if you are running an agency and have a lot of licenses, you would probably go for (B) or (C). It would be another cost of running the agency (just like you pay for an accounting software, backups, project management tools, etc).

    With (B) and (C) the agency is responsible for the updates cost, not their clients. After all, Perch targets the developers and companies that build sites with Perch, not the end client. We are the ones that benefit the most. If you run an agency and rely on Perch to deliver your work, this model seems reasonable in my opinion.


    On Perch's 10th anniversary Perch v4 was announced. The announcement also mentioned how the current license model has become unsustainable and that a new license model was proposed:

    To make sure we can dedicate developer time to supporting and updating the software, Perch 4 will be a charged upgrade and will include 12 months of support and updates. After those 12 months, if you wish to continue to receive updates and support, you’ll need to renew that contract at an additional cost, just as you’d renew your web hosting.

    In case it is not clear, to paraphrase:

    1. You purchase a v4 license
    2. You get support and updates for 12 months
    3. After 12 months, if you still want updates for this license, you can pay for another 12 months worth of updates. If you don't need the updates, you can keep using the license with the last Perch version that was released within the 12 months in (2).

    The announcement post discusses the reasons the current license model has become unsustainable, one of which is the fact that many older licenses are being reused for newer projects.

    With the new proposed model you would most likely pay for an additional 12 months worth of updates for a license if:

    1. the project requires on-going development/maintenance and you want to keep using the latest version of Perch
    2. you want to re-use an old license with a much newer Perch version (e.g. a project build on v4.1 (latest at the time). The project no longer exists a year later and you want to re-use the same license but with v4.5 which got released 12 months after v4.1)

    A lot of the Perchology Slack group members thought this was reasonable, but we recently found out that the proposed model got a lot of push back:


    What about Perch 4?

    When we announced the upcoming Perch 4, one of the significant changes we outlined was to the way Perch is licensed. Since then we've had a lot of feedback from our customers that a subscription model isn't something that will fly with their clients. We're listening, of course, and are currently investigating ways to move forward with Perch 4.

    So I created this thread for us customers to discuss the proposed license model here publicly.

    Hi robb,

    If you are on a development or staging environment, turn on debug mode by adding the following to your config file:

    1. define('PERCH_DEBUG', true);

    You should see a debug message below the log in form. Do you get any errors in the debug message after you submit the form to log in?

    Hello Marc,

    Yes, it can. How you implement this ultimately depends on your needs. At a minimum you can fetch the data from your external source, convert it into an array and render it using perch_template():

    1. $json = file_get_contents('');
    2. $data = json_decode($json, true);
    3. perch_template('my_template.html', $data);

    The above is not very practical as you probably do not want to fetch a large set of data from an external resource on every page load.

    If you do not need to filter/sort the data or paginate the output, you can write a custom Perch app to periodically fetch the data and save it in a file on your server. This way you do not need to download the data from your external source on every page load.

    Otherwise, you could write a custom Perch app to periodically fetch your data and import it into Perch Runway Collections (or your own custom database tables).

    Yes, you can:

    1. <perch:repeater id="contactDetailRows">
    2. <perch:if id="perch_item_index" value="2">
    3. P: <perch:content id="contactDetailItem" type="text">
    4. </perch:if>
    5. </perch:repeater>

    Or you can check against the value of contactDetailTitle if you know what it is:

    1. <perch:repeater id="contactDetailRows">
    2. <perch:if id="contactDetailTitle" value="Phone">
    3. P: <perch:content id="contactDetailItem" type="text">
    4. </perch:if>
    5. </perch:repeater>


    You cannot filter repeater items. You can remove the filter:

    1. perch_content_custom('Contact Details', [
    2. 'page'=>'/contact-us.php',
    3. 'template'=>'_footer_phonefax.html',
    4. ]);

    And update your template to only output what you need. Assuming phone number is always the first item:

    1. <perch:repeater id="contactDetailRows">
    2. <perch:if exists="perch_item_first">
    3. <!--* output the first item of the repeater *-->
    4. P: <perch:content id="contactDetailItem" type="text">
    5. </perch:if>
    6. </perch:repeater>

    While I am not against the idea of being able to duplicate content (page, block, repeater item, collection item, region item, etc), I don't think it is the ideal solution to your particular use-case.

    Even if the feature existed, every time you make a change to the desktop block you would have to delete the existing mobile block and duplicate the desktop block again.

    Ideally the editor would enter a piece of content once. The rest should be up to the developer. However, I understand how this can sometimes be tricky when building modular pages with Blocks.

    I personally would use a single editable section for this even if I need to output the same set of links multiple times with different HTML. I think it is the most user-friendly option for the editors. As a rule of thumb, whenever you find yourself (or your editors) having to re-enter content, it is a good time to evaluate your content structure.

    If it does not make sense to manage this in a block (for technical and/or editor-experience reasons), you can add the fields outside the blocks even if you still want to give the editors the flexibility to choose where the links are displayed via blocks. Perch is flexible in a lot of ways. You can add a block with a single select field to specify which style (desktop/mobile) links to output and bring the content from outside the blocks.