Posts by hus_hmd

Since the topic of first-party apps has been brought up, here are my thoughts. Any app that provides listing items and not much else can be replaced by Collections.

The Blog app is popular because it provides a preset way to handle things. It already has the required fields that are important for date-ordered dynamic content and comes with some functions that perform specific things instead of just the flexible perch_blog_custom(). We see it being misused for non-date ordered content possibly because developers with less PHP experience don't see multiple-item regions or collections as easy to use, or possibly because some developers are coming from a CMS where everything is a blog post (WordPress).

The same applies for the old Events app. The functionality it provides can be replicated by multiple-item Regions (for simpler sites) or Collections.

With the way Collections seems to be heading, I could see there being preset templates/configurations for Collections that can be distributed instead of an app for everything. Think about how many flexible tools nowadays provide templates: Airtable, Notion, Zenkit, Trello. This way there would potentially be less app development for Drew/Rachel and more time to invest in the core product. All new improvements to Collections would be applied for all presets. And the developer experience for those with less PHP experience would remain positive.

Though with this approach, Collections and relationships may need to be available in standard Perch too. Possibly with a limit on the number of items like JayW suggested.

I'm not saying I don't want apps. App development would still have its place. It is just not necessary for the simple list/detail cases.

Quote from JayW

Out of box thinking - I wonder what would happen if Perch was offered for free, and Runway increased by the price that Perch was? Or have a free edition where everything worked, but put hard limits on collection item/product counts? Marketing and incentives for new users are important, and these things could be improved for Perch.

I think many still prefer standard Perch over Runway, so assuming standard Perch sells more, it would be difficult to make it free.

I'm not sure limits on Collection items would work. A developer could build a Perch app that has no limits and use it instead. There is already some sort of limit on multiple-item regions so you'd need to upgrade to Runway Collections.

However, limits on Perch Shop products could certainly work!

Hi Andy,

Yes, you can control this. Perch gives you control over things, so a lot of the times when you want something to behave in a certain way you would be responsible for that; not Perch.

Assuming you are using a multiple-item region, it means you are using perch_contetn_custom() to fetch and output the item on the detail page. Perhaps something like this:

This only handles the retrieving of the item and outputting it. If on this page "not finding an item" means 404, you need to implement this behaviour as Perch does not assume how you want to handle this.

At the top of your PHP page, after your Perch runtime include and before you output anything to the page is the ideal place to handle this:

If you are using Runway, you can use:

Quote from charlie.elsey

looking back at Perch over the years I think it all started to suffer after the introduction of the shop add-on

Nice observation, charlie.elsey.

Some suggested that Shop should be a paid add-on. If it is being actively developed, I agree. I think the plan was to introduce the Shop Assistant (paid subscription) to generate recurring revenue from it. There is certainly an opportunity for them to charge for Shop.

Hi Simone,

I don't think this feature is available. However, you can default the new members to a pending status and manually approve them.

Despite of how negative I may sound, I'm actually sticking with Perch for the time being. I'm being overly critical because I think the feedback is reasonable and valuable.

I think as a product, Perch still has its place in the market. And just like Fathom Analytics went from almost being shut down to tripling their monthly recurring revenue with the launch of v2, I believe Perch v4 can breathe a new life into the product (and the business).

I am still excited about the direction of v4:

• Improved control panel UI
• Dark mode
• Cloud backups for regular Perch
• New add-ons directory (to which registered developers can publish their own add-ons)
• Open-source docs (it is already on GitHub)

And based on what we've seen on the forum:

• Drew posted a poll and when questioned about it his response indicated the he was working on improving the way add-ons are developed
• potentially a better way to manage routes
• possibly better indexing for Collection items
• a better more developer-friendly way to manage Collections
• perhaps some changes to revisions  
• built-in paired tag parser for template handlers

Plenty of work for a small team, but we know they are capable. Plus this is a major upgrade and the workload and the changes reflect that. Many on Slack shared their doubts on how good and modern the new control panel UI will be, so I hope it will exceed our expectations there.

The disappointing thing has been the prolonged radio silences from the Perch team, but I think this can change. Though we have to be mindful of how many customers they have so we cannot expect them to respond to everything and still invest a lot of time in developing the product. Besides, a lot of the site building questions can be answered by the community.

As Stephen Meehan stated, when you look at the update history page you can sense it is not being actively developed (although we know v4 is being worked on). First-party add-ons have been neglected too:

• Perch Shop requires one urgent update (for European merchants using Stripe) and that is yet to be addressed
• Perch Blog (widely used) has a few bugs (reported on the old forum last year)

If it is already unsustainable, we'll either see changes or see the product die. Move to a more sustainable model and lose some customers in the process? Keep the current model, the extremely low release frequency and poor communication in order to retain some customers, but lose the product in the process?

I don't care whether Drew/Rachel respond to this thread directly. This is more for us (customers) to discuss and share our thoughts which may give them some valuable feedback. For now regardless of what drewm and rachelandrew decide to do, I would love for them to communicate with us more (at least via announcements/tweets/blog posts). Frankly I don't think Drew/Rachel themselves would be happy customers if they were Perch customers at the moment.

Quote from Perch home page

There’s lots of free software out there, but there are also lots of dead and abandoned projects. You don’t want that for your clients.

Perch is not free, but seems closer to abandoned than actively maintained/improved. This is not something we want for our clients either. At least we can fork and improve an abandoned free open-source software if we really want to. We cannot do the same for Perch.

Quote from nilsmielke

mark their account as deleted for the admin to remove it from the app?

You can add a tag to the member with perch_member_add_tag(). So you can set up a form and on submission you can add a tag to the logged in member to mark the deletion/deactivation of their account, and log them out.

Without the moderator having to delete their user account, you can prevent them from logging in. You can use perch_member_has_tag() to check whether the logged-in member has the tag that marks the account as deleted:

Quote from nilsmielke

I am thinking of something similar to moderated registration, where the admin has to activate the member accounts.

This feature already exists. Go to Members > Forms and you should find the registration form listed there. You can enable the "New members require approval" option and enter the email address of the moderator so they are notified when a new member signs up.

Hi,

Quote from blythdev2k

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

You can install additional editors (https://docs.grabaperch.com/addons/plugins/installing/). TinyMCE is listed in the add-ons archive. Not sure whether it works on Perch v3 though.

Quote from blythdev2k

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:

• Editor plugins documentation
• Understanding Custom Editors Config

I see. Just note that if you are doing a content search (with perch_content_search()), the search results will include both the old and the new collections.

Hi Linda,

Are you using the default product file template templates/shop/products/file.html as is? Or have you made changes to it?

Hi,

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?

Quote from JordinB

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.

Quote from JordinB

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.

Hi,

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

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

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:

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.

Hello,

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:

Quote from Perch is Ten! Find out what comes next

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:

Quote

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,

Quote from Stephen Meehan

Is this a safe way to replace text in a database?

You would be bypassing the software (Perch and any installed add-ons), so any process Perch performs upon updating this record would be bypassed too (e.g. updating cache, index, revisions, event hooks, etc).

Hi robb,

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

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():

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).