Posts by hus_hmd

  • using content_custom to pull data from a repeater field

    Yes, you can:


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


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

  • using content_custom to pull data from a repeater field

    Hi,


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


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


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

  • Can repeater content be duplicated?

    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.

  • Display blog section in search results

    If the post URL does not include the blog slug (which would correspond to the language in your case), you could use perch_blog_custom() to look up each post and include/exclude it from the search results accordingly.


    PHP
    1. $post = perch_blog_custom([
    2. 'skip-template' => true,
    3. 'filter' => 'postURL',
    4. 'value' => $item['result_url'],
    5. 'blog' => $lang,
    6. ]);


    This means you'd be making more database queries on the page though.

  • Display blog section in search results

    From the screenshot it looks like you are using multiple Blogs, which is different from Blog Sections.


    Anyway, I don't think there is a straightforward way to only include posts from one blog (e.g. the DE blog) in the search results. There are workarounds though.


    One option is to get all the matching items, skip the templating, filter the items in PHP and output the filtered items with perch_template():


  • Display blog section in search results

    Quote from dcus2018

    Each language sets a global variable dependant on the url and I need to filter the search results from the source relative to the blog section


    If I understand correctly, you'd like to display the results in the same language as the global variable you're setting. Is this correct? For example, if you are on /de/search, you want to only display results with URLs that start with /de?

  • Paging link rewrite not picking up section token/slug

    I ran into this issue yesterday myself. I'm sure I came across it in the past too. I often end up just using URL query string ?page=. So hopefully drewm will address this in v4 at least!


    Thinking about it now, you probably can use Perch conditional tags as the named segments you use in URL patterns are available to you (prefixed with url_)


    HTML
    1. <perch:if exists="url_section">section/<perch:blog id="url_section">/</perch:if>

  • Non-latin characters in page paths and slugs

    Hello,


    I would like to be able to use non-Latin characters in page paths and slugs. It is not uncommon to use non-Latin characters in page paths. Here is an example: https://ar.wikipedia.org/wiki/المملكة_المتحدة


    It seems page paths (automated generation on page creation), the slug field type and PerchUtil::urilify() do not handle this.


    Based on what I attempted it seems the page paths need to be url encoded in the database for Runway to be able to find the page. The above example would need to be:

    Code
    1. https://ar.wikipedia.org/wiki/%D8%A7%D9%84%D9%85%D9%85%D9%84%D9%83%D8%A9_%D8%A7%D9%84%D9%85%D8%AA%D8%AD%D8%AF%D8%A9


    And this also extends to routes as non-Latin characters in URL patterns need to be encoded too.


    In Perch Runway 3.x I'm working around this with:

    1. a custom route token
    2. a custom slug field type
    3. Javascript that I'm adding to the control panel to encode the value of the relevant fields before form is submitted


    I'm ok with (1) and (2). Perch is designed to handle this sort of customisations. However, (3) is a little hacky. It would be nice if Perch Runway v4 tackles this.



    Use cases:

    • Building non-English websites
    • Building multi-lingual websites
    • Migrating from a CMS that supports this to Runway - e.g. I was tasked with migrating some blog posts from a WordPress site to a Runway Collection. Some of the WordPress posts had URLs that contained non-Latin characters.