Posts by nilsmielke

    I have recently had weird problems with the Backup App (current version in Perch 3.1.7) not running as expected.

    Initializing a backup in Admin always led to the following error in an otherwise blank page in the browser:

    1. File 'backup/backup.sql' does not exist [code -4]

    The server admin came across the following error in the Apache error logs:

    1. sh: 1: Syntax error: ")“ unexpected

    As that didn’t give a lot of background info, the server admin started digging deeper and at some point came to the revelation, that it might be related to a closing bracket in the DB password.
    Changing the password solved our problem.

    Nonetheless, this problem should not occur in the first place.

    We suspect it originates from line 69 in PerchBackup.class.php:

    1. exec($mysqldump_path.' --opt --host='.PERCH_DB_SERVER.' --user='.PERCH_DB_USERNAME.' --password= '.PERCH_DB_PASSWORD.' '.PERCH_DB_DATABASE.' > backup/backup.sql’);

    Here, the characters in PERCH_DB_PASSWORD, that might cause harm, should be escaped.

    Please consider updating the Backup App asap.

    Thank you.

    Thank you rachelandrew and drewm for all your hard work on Perch (and in the web community in general). All the best for your future endeavors.

    Welcome to the “family” (it does get very snugly in the Perch Slack at times 😋), George G and team.
    I am looking forward to working on many more Perch-powered websites.

    The problem seems to have been (I will not hold my breath it will run smoothly for too long, as I had quite a few Perch-related issues with this project already), that I referenced the site’s root inside my download.php like this:

    1. <?php
    2. $root = $_SERVER['DOCUMENT_ROOT'];
    3. include($root . '/perch/runtime.php');

    Changing that to the actual, relative path like so solved the issue:

    1. <?php
    2. include('../../perch/runtime.php');

    I used the former on the old server without problems and still use it to include the /perch folder in all other pages. Only for the download.php file it broke functionality.

    Hey forum, hope you can help me solve this.

    I have a client website (standard Perch v3.1.7) with the Members App installed. I set up secure downloads as described in the docs (…mbers/examples/downloads/).
    When there is more than one secure download displayed in a page, the first download initiated works as expected. Trying to start a second download, though, fails. The browser (Firefox on macOS in my case) reports “failed” (in the screencast “fehlgeschlagen” as it is German).

    When SHIFT-reloading the page (to purge the browser cache—no pun intended), the download of a second file works. Every try after that fails again.

    Here’s the screencast (MP4, 22s):

    At 00:15 the page is SHIFT-reloaded.

    I had this working before, but had to move servers, as the hosting company retired the old infrastructure.

    I checked the error logs and was in touch with the hosting provider, but there does not appear to be an issue with the hosting and/or server setup.

    Any ideas, how to attack this from a different angle, are appreciated.

    Cheers, Nils

    Here’s the (short) diagnostics summary:

    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.

    Many thanks hus_hmd, the Add Tag way is a pretty good idea.
    I will have to figure out, how to either notify the moderator of that, so he/she can delete the account for good, or how to automate that with a cronjob.


    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.

    Yeah, I know, I was just giving that as a reference, to how I would like the detetion to work. 😊

    Is there a function available for members registered through the Members App to delete their account—or mark their account as deleted for the admin to remove it from the app?

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

    As someone who has benefitted from re-using licences, I've even been given a few old and unused ones, it seems way to generous. I'd accept licences being permanently locked after a year. A new project should mean a new licence.

    Couldn’t agree more.

    I agree with almost everything written here before me. Here’s my two cents, though.

    1. More communication = less uncertainty
    I love working with Perch and would love it to evolve and prosper. I don’t care too much, when v4 will land, but to keep selling Perch to my clients, the occational sign of life would be helpful. With every quote I write, I am pondering whether or not to propose Perch and whether or not to quote for an ongoing maintenance fee. It could be considered easy money, if there is only one update a year, but that makes you wonder, where Perch is headed and might lead to unpleasant discussion with clients. (Also, an approximately bi-monthly update cycle, gave us a good “excuse” to be in closer touch with clients.)

    2. Subscriptions are not for everyone
    As for the pricing model: We are a tiny two-man-show of an agency, sometimes outnumbering the headcount of the companies we work for. Some of those wouldn’t care for a monthly subscription. Some already opt for not buying the ongoing maintenance. Our bigger clients wouldn’t object, I suppose, as long as they get value for their money—in the form of more regular updates.

    I think, Hussein’s suggestion would work quite well for us.

    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.

    Depending on the cost of (B) and (C), another option (D) could be to decide per licence, if it should run on a subscription or not. That we could factor in with the ongoing maintenance, some of our clients choose to buy.

    I know, Perch probably cannot serve everyone and every scenario, if it should stay/become sustainable. It did that pretty well for us in the past, though, and I enjoy using it even on the smallest of projects.

    Hi Design,

    here’s how I have done it:

    In your page (e.g. “project.php”), after including Perch‘s runtime.php and before including the header, tell Perch what image to use.

    Then in your header.php set the meta tag for og:image with that image:

    1. <meta property="og:image" content="<?php print PerchSystem::get_var('ogimage', true); ?>" />