Search the Community

Hi, I know that similar postings have been made, but the discussions and the code therein were way over my head. Here's my problem: I created a website on my local machine that used repeater fields. Everything worked. I transferred it to the dev server online using the Export Site Profile module. Everything worked there, too. Here my memory is a little murky, but I believe that I added some fields to templates that caused pages with repeaters to generate about 1000 new invisible, system-level pages each time they were edited. (This may be what renobird discussed here: <http://processwire.com/talk/topic/3619-updating-repeaters-via-api-without-removeall/>) So I fired up phpMyAdmin and manually deleted all those pages -- and probably some that I needed for the repeaters. I cleared the cache. I turned the Repeater inputfield off and on. But now I can neither delete the existing repeater fields in the admin nor create new ones. I tried importing a sql dump of a repeater field from the original system but that didn't solve the problem either. Can anyone tell me if there's a way to fix this? I really need to use repeater fields for this website. I've built a few sites with PW and feel quite comfortable with it but I haven't plumbed the depths of the API yet and have only the most rudimentary PHP skills. Even so, it's amazing how much I can get done. But, as you see, it's still possible to get stuck when you go beyond your depth. Your patience is much appreciated. Cliff

Hello all, I've been using repeater fields for many purposes. Mostly I use it to store multiple entries of similar kinds of data in a single page. A while ago Ryan answered one of my questions related to repeaters here. That is when I started wondering if I'm misusing the repeaters and probably will have to pay for it later when the site grows. So this question is just to understand the Do's and Don'ts about repeaters. I hope this will be informative for everyone & useful for not so bright people like me. Thank you.

Hey guys, I am confused: my repeater fields are not saved from the API. Here's the setup: 1. A repeater (named 'faqQA') which contains 2 fields: 'title' and 'body'. 2. A template containing the above repeater. 3. A page that uses that template and has one instance of the repeater. Everything was created in the admin back-end. Repeater values were filled with sample text. (The repeater is supposed to be a FAQ item collection). This is the code I have in my template: $cFaqPage = $page; $cFaqPage->of(false); $faq = $cFaqPage->faqQA; $cFaqPage->faqQA->get(0)->title = '1'; $cFaqPage->faqQA->get(0)->body = '1'; $cFaqPage->save(); echo $cFaqPage->faqQA->get(0)->title; // outputs "1" echo $cFaqPage->faqQA->get(0)->body; // outputs "1" die(); The script is supposed to update the values of the repeater fields with some new values, and to exit. However, when I run it and go the the admin back-end to check the page, I still see the old values in the repeater fields. This is quite sad, and I stripped my code down to basics and it's still not working. Any ideas where to look at? Thanks for your support in advance.

Hi, I am using the basic search template from the processwire install. I havn't been able to return any search results from text contained in repeater fields. I have added the repeater field name and all fields contained inside it to my search template. On processwire.com i have found this post in the comments area by someone: Is there any way around this, or are repeaters left out of search results? thanks Alex

Hello there - So I'm migrating an existing yoga studio site that I built into ProcessWire. I created a template for the "teachers" page, which has teacher bios, that uses repeating fields for each teacher & wraps each one in a section tag: <?php foreach($page->Info_Block as $Info_Block) { ?> <section class="bio"> <? echo "<h2>{$Info_Block->Name}</h2>"; echo "<div><img src='{$Info_Block->Image->eq(0)->url}'>"; echo "<p>{$Info_Block->Information}</p></div> "; }?> </section> I would like to make it so that only the teachers' names show, and then the bio section opens when the name is clicked, which I've done with CSS on the existing site: http://saniyoga.com/teachers.php. But the pure CSS solution uses modified inputs, which doesn't seem like a viable solution here. I've tried adding the script for the JQuery UI accordion to the template in both its original form (the containing div for the above code is "dropdown_cont") $(function() { $( ".dropdown_cont" ).accordion(); }); .... and with a modifier to take the section into account, $(function() { $( ".dropdown_cont" ).accordion( { header: '> section.bio > h2' } ); }); but it doesn't work. Still very new to ProcessWire so would appreciate any suggestions.

In the "search.php" template that comes with the download of PW, this line allows you to search for "title", "body" and "sidebar" fields: $matches = $pages->find("title|body|sidebar~=$q, limit=50"); But how do you search for content inside a repeater field? Thanks.

We encountered a performance problem with a custom search today, finding out that one particular database query lasted seconds. Digging deeper revealed it has to do with repeaters when there are enough of them. The site has pages for companies (about 1500 of them) each of which has repeater items attached. Most of them have one single item, total amount of repeater items being under 2000. This leads to about 3500 extra pages in the tree as a penalty for using repeaters (yes, there would have been other possible approaches as well). So, the amount of pages isn't anything massive. Now, when a find("parent=/companies/, title%=keyword") is executed, the repeater fieldtype catches the use of title field (used in the repeaters as well) and tries to ensure no repeater pages get returned by adding !has_parent=<repeaters-page-id> to the selector string. While this is logically right, the resulting SQL query becomes slow due to the extra join used to filter out repeater pages. With those 1500 + 1500 + 2000 = 5000 pages there are about 9000 rows in the pages_parents table (which is used for implementing has_parent selector). This isn't that much either, but it becomes a problem when there's a join between pages and pages_parents. I'm not saying it wouldn't be possible to optimize the query, but as I'm not certainly skilled enough to do it, I went down another road. And the solution is dead simple - actually it's possible to catch it by just looking at those bolded selector strings above . Ready? Ok, if we're searching for pages whose parent is /companies/ why should pages under /processwire/repeaters/ be explicitly filtered out? There's no way they'll match, so we'll just skip the extra repeater filter. And if you we're actually trying to find pages under /processwire/repeaters/ you didn't want the filter to kick in either (well, don't do that anyways, they're internals). Here's a little diff showing the change I made to fix this thing for us (there's a pull request on the way Ryan): $ git diff diff --git a/wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module b/wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module index 20bb52c..ab9db28 100644 --- a/wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module +++ b/wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module @@ -138,6 +138,10 @@ class FieldtypeRepeater extends Fieldtype implements ConfigurableModule { // ensure that the repeaters own queries work since they specify a templates_id if($name == 'templates_id' && in_array($selector->value, $templatesUsedByRepeaters)) $includeAll = true; + // optimization: if parent (or parent_id) is given, there's no need to explicitly exclude repeaters + // TODO: has_parent with values other than parents of repeaters-page could be catched as well + if($name == 'parent' || $name == 'parent_id') $includeAll = true; + if($includeAll) break; } } Another performance issue solved. Not a very common one I think, but still worth a fix. Edit: Ryan, no pull request this time. Didn't manage to do it right. Next time there'll be a branch before any changes, maybe that'll do it.