Jump to content
DarsVaeda

[solved] frontend edit on repeater fields

Recommended Posts

Hi,

how do I enable frontend editing for repeater fields?

It partially works with 

foreach($page->repeater_field as $item) {
>?
<li><edit list_item><?= $item->list_item ?></edit></li>
<?php
}

But if I click a frontend item the text disappears. I'm not sure if this is a bug or because it does not know which text it should reference.
I tried with:

foreach($page->repeater_field as $item) {
>?
<li><edit list_item_repeater<?= $item->id ?>><?= $item->list_item ?></edit></li>
<?php
}

But that results in an exception.

Share this post


Link to post
Share on other sites

Hi,

could this be related to permissions?

We currently encounter problems with frontend editing of repeater fields, too: in our case it's simply not possible to frontend-edit repeater fields for users with a specific role, although these users are able to edit the respective repeater fields in the regular backend page editor. Superusers are able to frontend-edit repeater fields as expected.

@DarsVaeda this is an example of how we included frontend-editing which works (apart from the problem described above):

<?php 
/** @var RepeaterPageArray $attributes */
foreach ($attributes as $attribute): ?>
  <div class="attribute">
    <?php $image = $attribute->get('image'); ?>
    <div class="attribute__image" edit="<?php echo $attribute->id; ?>.image">
      <img src="<?php echo $image->url; ?>" alt="<?php echo $image->description; ?>">
    </div>
    <div class="attribute__body">
      <?php echo $attribute->edit('body'); ?>
    </div>
  </div>
<?php endforeach; ?>

 

Cheers, Alex

Share this post


Link to post
Share on other sites

Hmm maybe, I need to try but I only have one user currently who is admin.
But now after updating I have the problem that all fields get "deleted" when starting to edit.
I'm not sure if it's my implementation or a bug. Need to dig into this.

Share this post


Link to post
Share on other sites
On 23/01/2017 at 8:14 PM, DarsVaeda said:

I tried with:


foreach($page->repeater_field as $item) {
>?
<li><edit list_item_repeater<?= $item->id ?>><?= $item->list_item ?></edit></li>
<?php
}

 

This is the actual problem. It doesn't work with this implementation.
If I use this:

foreach($page->repeater_field as $item) {
>?
<li><?= $item->edit('list_item') ?></li>
<?php
}

Then frontend editing works.

Thanks @design-a-point!

Share this post


Link to post
Share on other sites

I had the same issues you both mentioned. When logged in with some other role then superuser and try to edit a page, either the text disappeared or I wasn't even able to edit the text, at all.

The problem comes up, if you want to use option B (explained here: https://processwire.com/api/modules/front-end-editing/ ) for front end editing. 
I chose it above the other options, because of its direct "inline access" (compared to the dialog box with option C and D). Because repeater fields are stored as child of the admin page in the backend, other user roles don't have access to them by default, which leads to the afore mentioned issues, I guess. 
My solution was to give those user roles access to the admin page template and its children.

It took me some time to discover it, so if other users have problems with this, as well, maybe it's worth mentioning it in the module docs somewhere?

Share this post


Link to post
Share on other sites
23 minutes ago, Christoph said:

It took me some time to discover it, so if other users have problems with this, as well, maybe it's worth mentioning it in the module docs somewhere?

Did you check the front-end editing documentation when investigating your problem? It specifically advises against using option B for Repeaters:

Quote

But not worthwhile for things like Files/Images, PageTables, Repeaters or any field that you iterate to output or access object properties from. For those you will want to use <edit> tags or edit attributes, per options C and D.

 

  • Like 1

Share this post


Link to post
Share on other sites

Yes, I read it. 

As I had no problems using option B with repeaters as a superuser, I just wanted to make it work for other user roles, too. Option C/D is just no real front end editing any more, at least regarding how my clients understand it. In my current client's context, the front end editing is just needed to correct typos and the likes.

But you are right, as there is a strong advice to not use option B in a repeater context, the docs don't need to provide a solution on how make it work :).

Share this post


Link to post
Share on other sites
1 hour ago, Christoph said:

Option C/D is just no real front end editing any more, at least regarding how my clients understand it.

It is only option D that forces the modal dialog editor. Option C allows inline editing - you just have to place edit tags around the individual fields in your repeater rather than around the whole repeater foreach(). For example:

<?php foreach($page->my_repeater as $item): ?>
    <h3><edit <?= $item->id ?>.title><?= $item->title ?></edit></h3>
<?php endforeach; ?>

You're right that there does seem to be some sort of permissions issue for non-superusers, but rather than change access for the admin template (which non-superusers shouldn't have access to) I suggest you give edit access to your repeater template (select the "Show system templates" option to see repeater templates).

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites
On 08/02/2017 at 10:00 AM, Robin S said:

Did you check the front-end editing documentation when investigating your problem? It specifically advises against using option B for Repeaters:

 

Is that documentation up to date? It doesn't work for me with option C. I get a popup which is not usable. Would need to dig into what is wrong with the html/css.
But option B works for me without any problem (despite the need to set the permission on the system template as you suggested).

Share this post


Link to post
Share on other sites

@DarsVaeda Had the same issue with unusable popup on option C/D. My solution was to change the jQuery version to the one processwire is using.

@Robin S Thanks for your help! Will try your solution with option C later today. You're right, instead of changing the admin template, it is enough to allow access for the repeater_content template

Share this post


Link to post
Share on other sites

@Robin S I tried your code snippet for option C and it worked. Wondering though, where's the difference to option B in this case?

Share this post


Link to post
Share on other sites
9 hours ago, DarsVaeda said:

But option B works for me without any problem

5 hours ago, Christoph said:

where's the difference to option B in this case?

Re-reading the docs, I'm not sure why Ryan advises against using option B with Repeaters or PageTables (for Files/Images fields it makes sense). Maybe he means if you are wanting to make the entire Repeater/PageTable field editable rather than the individual fields inside the items, because it does seem to work fine for the latter case (once the access bug is worked around).

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By ICF Church
      Hi 👋
      Anyone else having this problem?
      Requirements:
      - Repeater (matrix & normal) with mutlilanguage fields (text, textarea…) 
      - Backend language set to something other than default (ie. German) 
      Reproduce:
      - Add a new repeater Item (ajax, I found no way to possible to disable it with matrix)

      (Notice how the default language tab is active instead of the backend language…)
      - Write something into the (default language) field
      - Try to save, if field is required, this will not work. If not required, then when reloading, the content will be inside the backend language field, instead of the default language field who was (presumably) active
      Analysis:
      When  loading  a new repeater element with ajax, the default langue tab is active, but the backend language inputfield is visible (with no visual indication). When writing into the field, it will populate the backend language. When manually clicking on the default language tab (which is already active), the field will switch to the actual default language field (which is [now] empty) (that can now be populated…)
      Also Notice, the labels of the elements to be added are in default language as well instead of the translated label (images instead of Bilder)…
      ProcessWire 3.0.148, Profields 0.0.5…
      Is it my system configuration, or does anyone else have the same issue? This is a screen recording of the problem:
      Issue: https://github.com/processwire/processwire-issues/issues/1179

      Screen Recording 2020-02-25 at 14.18.31.mov
    • By neonwired
      I have a front end form for creating new pages, repeater and repeater matrix field don't seem to save any data. I was considering handling the data manually but can't seem to get anything useful from the post data, are there any methods i can use?
    • By neophron
      Hi,
      I'm having trouble with a maybe simple code:
      I created a repeater (gallery_logos_links) and a repeater matrix (RepeaterMatrix_unternehmen). The repeater (gallery_logos_links) is inside the matrix repeater as a matrix type.
      The repeater matrix type is: gallery_logos_links and the image filed from the repeater is single_image.
       
      This my code:
      <?php foreach ($page->RepeaterMatrix_unternehmen as $item) { if ($item->type == 'gallery_logos_links') { echo " {foreach($item->repeater_logos_links as $logo)} <img src='{$logo->single_image->url}' alt='{$logo->single_image->description}' width='400'> {endforeach} "; } else if ($item->type == 'some_stuff') { echo"  
       
    • By shadowkyogre
      [EDIT]: After sitting down and planning out my site according to the ragged hierarchy information, I settled on the following schematics.
      /$world/$template/$content_of_template_type/... for my pretty URLs /roster/$character for my characters a generic Repeater field with depth on most content types for custom positions for child pages to connect to instead of it directly a few Repeater fields on each content that have (PageReference[1], other fields) to establish associations A few FieldsetGroups to help me manage the fields that I needed to copy across a bunch of content types. Kept the original post below for context and tagged the OP for searchability.
      ---
      Hi everyone! I'm working on a personalized worldbuilding wiki to host my art and story stuff.
      Right now my site architecture looks like...
      /$world/cosmology/$cosmology /$world/locations/$location /$world/factions/$faction /$world/history/$history /$world/species/$species /roster/$character So far the layout works, but there's one problem. I need to make sub-sections for an organization. Organizations can appear under cosmology, locations, and factions. Sounds straightforward until... I run into the problem of figuring out how to represent subfactions.
      Key factors in this are...
      Characters should be able to be part of multiple organizations Characters should have an explicit role assigned to their membership. Character pages should be able to query the organization pages to display their ranks across organizations. Editing an organization's hierarchical layout should be visible while editing the root organization page. From what I've read of the ProcessWire documentation, the best use case for each way of representing the organization's subsections are...
      Child Pages:: Works best for menu presentation and dedicated editing. PageTables:: Works if you want control over where to place the PageTable fields, but requires opening a modal for the pages you want to edit. It's also kind of like normal pages. Repeaters:: Works great for inline editing and easy control over hierarchy, but the page urls become obscure. Sections in the body field:: Works for copypasting from my note files. But it doesn't expose relationships for easy querying. It looks like my best case for this is child pages since it allows displaying suborganization in the URL easily. But also I lose out on quickly reordering and editing the child pages. Any advice for people running into similar use cases?
    • By benbyf
      Hi, Looking to create form elements on a page–some input with a colection of form inputs and the appropriate labels and variables for that input. I've used ProForms in the past and rolled out my own when creating simply one off forms, but I wonder if anyone has found a good way of allowing form creation on page editing so that clients can adhocly make and edit forms?
      Thanks
×
×
  • Create New...