Posts by hus_hmd

    e.g. tags that just duplicate content or else hidden tags?


    Duplicate tags: Perch just checks the first occurrence of the tag in the template used for the edit form only


    Hidden tags: they won't be indexed regardless. Though Perch automatically indexes some data (e.g. _id) regardless of whether you use it in the template.




    2. I think the performance gains you are talking about are not worth worrying about.

    This largely depends on how much content you have. I've decreased the collection index table by about 60% for a client by limiting what fields get indexed and the number of revisions. Besides the performance gains, even the size of backups becomes noticeably smaller (which can be a business factor if you pay for cloud storage).


    Having said that, it is not necessary to be very strict about this from the start particularly with smaller projects and regions. Limiting the number of revisions with PERCH_UNDO_BUFFER from the start like ellimondo suggested is probably a good idea.

    Hi,


    The rule of thumb is that any field you do not need for filtering or sorting does not need to be indexed. In the context of an article:



    PHP
    1. perch_content_custom('Articles', [
    2.     'sort' => 'date',
    3.     'sort-order' => 'DESC',
    4.     'filter' => 'status',
    5.     'value' => 'Published',
    6. ]);



    Saying that, however I have used Perch PHP commands to retrieve data from the database to re-use in Perch templates so if for example, I marked every field with no-index, would I at some stage run into trouble?

    If you don't need any of these fields for filtering or sorting, you should be fine. If there are fields that you think you may need to filter/sort by in the future, you can either reindex in the future when needed or start indexing these fields from the start.



    Also, what would happen to the database in terms of previously indexed content, i.e., would my database shrink?

    Not immediately. You need to resave the content for Perch to reindex them. For regions, you can use the page republish option.


    In order for the revision indexes to also be updated in the database, you need to resave multiple times (otherwise the number of rows in the index tables may not decrease).


    You can also configure how many revisions Perch keeps in the database in your config file (fewer revisions = smaller database tables). See PERCH_UNDO_BUFFER https://docs.grabaperch.com/perch/configuration/perch/


    PHP
    1. define('PERCH_UNDO_BUFFER', 3);

    About the above quote though. How is the current situation (uncertainty and stagnation) an improvement to launching v4 with a licencing model that some customers objected to? How much of v4 is ready? What's is there to lose at this point by going ahead with v4 as planned? I don't mean to sound flippant, I'm genuinely interested.

    Investing time into completing v4 knowing that they are likely to lose sales/customers (based on the feedback they received from customers) while having already seen their revenue decreases due to customers reusing old v2 licenses on new v3 projects can understandably be seen as a risk.

    A relevant message I sent on Perchology Slack that I want to share here too:

    Quote

    I think open sourcing Perch without changing anything about the licensing is unwise. They reached a point where they needed to change the licensing model to ensure recurring revenue (and justify the development of Perch). They proposed to change the model to charge an annual fee for updates (which is totally optional) and what they got in return from a lot of customers is a giant middle finger. Screw that!


    Sponsorware is open source. It ensures they reach a target of monthly revenue (of their choosing) before it is open to everyone. Until that happens, you only get it access if you are paying for it. Those who opposed the annual fee for the updates are not happy to pay for things either way. Might as well exclude them until the target is reached.


    Support can still be a paid service (like it is the case with many open source projects). You get community support for free. Unless you are paying x/monthly you don't get first-party support.

    The product doesn't make enough money to justify two people working on it.


    Would sponsorware licensing be a good alternative to the current licensing (for v4)?


    It feels like we are at a stage where rachelandrew / drewm cannot realistically commit a lot more time without making sure the product generates enough money, and on the other hand those who want to continue to use Perch seem to feel like it is too risky to do so if the product is no longer actively developed. I'm not sure we'd get anywhere this way. Neither side seems truly satisfied.


    A sponsorware license ensures a somewhat two-way transparency and I think it may be easier to manage expectations for both sides this way.

    Hi James,


    If you are in the context of a list, you can use the variable perch_item_index:

    HTML
    1. <perch:content id="perch_item_index" type="hidden">


    If you're using the Blog app, use the perch:blog namespace.

    Does the template model.html have a perch:related field to relate documents to models?

    HTML
    1. <perch:content id="model_name" type="text" label="Nombre del modelo" title>
    2. <perch:related id="tech_specs" collection="Documentos"></perch:related>



    It looks like you are relating models to documents in document.html, which is absolutely fine, but it means you need to use perch_collection() to get or output these documents:


    PHP
    1. perch_collection('Documentos', [
    2. 'template' => '_v__document_es.html',
    3. 'filter' => 'model.slug',
    4. 'value' => perch_get('s'),
    5. ]);

    Hi Juan,


    • Are you using the related field inside a content region or a collection item?
    • If you turn on debug mode, the debug message should indicate whether Perch is able to find the template content/document.html
    • Try avoiding hyphens in IDs. So instead of tech-specs, use tech_specs


    The id template attribute is a unique identifier for the content field. It is a required attribute. Use letters, numbers and underscores only for an id.

    JayW I think the problem isn't with displaying the appropriate price (regular/sale/trade), but rather with what price Perch Shop uses for the cart and order. To check the current price of a product as Perch Shop sees it (and would use in cart and order), you can use current_price:

    HTML
    1. <perch:shop id="current_price" type="shop_currency_value">


    If, for instance, you enable the trade price with perch_shop_enable_trade_pricing() and a product has no trade price set, Perch Shop defaults the product's price to 0 instead of falling back to the regular price. Understandably this is not the desired behaviour in most cases.

    Hi Charlie,


    One option is to write a template filter to calculate the age. Another option is to calculate it with a callback function using the each option:


    PHP
    1. perch_content_custom('Cars', [
    2.     'each' => function($item) {
    3.         // calculate the age from $item['manufactured_date']
    4.         // age hard-coded for demonstration
    5.         $item['age'] = '3 years';
    6.         return $item;
    7.     }
    8. ]);

    Your perch3_content_index table looks a little large so I suspect it is taking Perch longer to update the indexes and revisions when you save a region.


    My advice is to first test in a development environment to rule out a recently introduced server change as the cause. If you do get the same result, then you can look at reducing the size of your content index table.


    (1) Reduce the number of revisions kept in the database

    Add the following to your Perch config.

    PHP
    1. // Number of revisions for Collection and Regions
    2. define('PERCH_UNDO_BUFFER', 2);



    (2) Tell Perch to not index all fields

    Add the no-index attribute to fields you don't need for filtering or sorting. For some regions that can be all fields.


    HTML
    1. <!--* do not index images *-->
    2. <perch:content id="image" type="image" label="Image" no-index>
    3. <!--* index slugs *-->
    4. <perch:content id="slug" type="slug" for="Title">




    Note for this to take effect, you need to republish the pages a few times (Pages > Republish button on the right). It would probably be wise to test this on a development/staging environment first.

    My bad. You need to also specify the template when using perch_content_create():


    PHP
    1. // using perch/content/text.html
    2. perch_content_create('Unicorn', [
    3. 'template' => 'text.html',
    4. ]);

    I see. When I wrote that field type I didn't think about it being used this way, but it makes sense.


    For now you need to filter by field_id_{index} which is not ideal unless you already know how many products you linked (e.g. if you use the max attribute to limit the number of products that can be selected):


    I opened an issue on GitHub as I think this can be improved.

    But when I do it like that, I don't know how to edit 'Content - Main' as it doesn't show up as a region.


    There are 3 content functions:


    1. perch_content_create() - creates a region if it doesn't exists
    2. perch_content() - creates a region if it doesn't exists and outputs cached HTML; Perch template is rendered when you save the region and then cached - so the template is not evaluated every time someone visits the page
    3. perch_content_custom() - outputs the region; Perch template is evaluated at runtime (i.e. when someone visits the page)




    So to use perch_content_custom(), you need to create the region first with perch_content_create() (or perch_content() where applicable):


    It is not possible to pass variables to the template when using perch_content(). Use perch_content_custom() instead:

    PHP
    1. PerchSystem::set_var('pharmacyName', 'Page Title');
    2. perch_content_custom('Pharmacy Contact Form');



    You can use the data option if you want the variable to only be available to this region:

    PHP
    1. // can access pharmacyName
    2. perch_content_custom('Pharmacy Contact Form', [
    3. 'data' => [
    4. 'pharmacyName' => 'Page Title',
    5. ],
    6. ]);
    7. // cannot access pharmacyName
    8. perch_content_custom('Another Region');