Pages Listed Under Repeaters in Admin

[quickjeff]

Hi Guys, 

I have been using Processwire for years now and have mastered enough to create some amazing sites and applications. 
However, recently I have been thrown a bit of a curveball and hoping some more veteran members can chime in. 

I recently ran into a weird issue. I had imported about 100+ wordpress pages into a new Processwire site using namespaces. 
I imported them under a parent page called /landing-pages/.

However, I needed to move 20+ of these imported pages to a new parent page called /customers/.

Since I was moving so many, I figured batcher was a solid module to run this task.

Here are the steps I took:

1. Located all the pages I needed using batcher
2. Changed the pages templates
3. Located the pages again after changing their template
4. Made the pages hidden and then located them again using batcher
5. Changed parent page from /landing-pages/ to /customers/

The issue that occurred is that not only did I change the parent page for these pages but apparently the pages also existed under /admin/repeaters/for-field-whatever which now changed to the new parent of /customers/.  

for-page-1625

admin

/admin/repeaters/for-field-108/

So I reverted this by using batcher again, here are the steps I took:

1. Located all the pages that were not supposed to be moved 
2. Changed the pages parent back to /admin/repeaters/

The issue is, after this was done, every time I clicked the new page under /customers/whatever-page I would get a 404. 

To correct this I had to delete all the pages under /admin/repeaters/ and /admin/repeaters/for-field-whatever and then go back and delete the pages under /Customers/ and create them all from scratch. 

 My questions are: 

1. Why did Processwire create pages under /admin/repeaters  for the imported pages?
2. The steps I took to correct this issue, is this okay to keep building the site or am I better off starting fresh again?

 

[abdus]

Repeater items are actually pages, and stored under /admin/repeaters/. If a template includes a repeater field, and you create a page using that template, a new repeater parent page is created under /admin/repeaters to house new repeater items for that specific page and a specific field. Changing the page's name or parent later on doesn't have an effect, because repeater parents use page and field ids for referencing which repeater items belong to which page and which field.

<?php 
// FieldtypeRepeater.module

/**
 * Return the repeater parent used by $field, i.e. /processwire/repeaters/for-field-name/
 * 
 * Auto generate a repeater parent page named 'for-field-[id]', if it doesn't already exist
 *
 * @param Field $field
 * @return Page
 * @throws WireException
 *
 */
protected function getRepeaterParent(Field $field) {

    $parentID = (int) $field->get('parent_id');
    if($parentID) {
        $parent = $this->wire('pages')->get($parentID); 
        if($parent->id) return $parent; 
    }

    
    $repeatersRootPage = $this->wire('pages')->get((int) $this->repeatersRootPageID); 
    $parentName = self::fieldPageNamePrefix . $field->id; 

    // we call this just to ensure it exists, so template is created if it doesn't exist yet
    if(!$field->get('template_id')) $this->getRepeaterTemplate($field); 

    $parent = $repeatersRootPage->child("name=$parentName, include=all"); 

    if(!$parent->id) {
        $parent = $this->wire('pages')->newPage(array('template' => $repeatersRootPage->template));
        $parent->parent = $repeatersRootPage; 
        $parent->name = $parentName;
        $parent->title = $field->name; 
        $parent->addStatus(Page::statusSystem);
        $parent->save();
        $this->message("Created '$field' parent: $parent->path", Notice::debug); 
    }

    if($parent->id) {
        if(!$field->get('parent_id')) {
            // parent_id setting not yet in field
            $field->set('parent_id', $parent->id); 
            $field->save();
        }
    } else {
        throw new WireException("Unable to create parent {$repeatersRootPage->path}$parentName"); 
    }

    return $parent; 
}

If you change the template and the new template does not have the same repeater field, then the repeater parent and all its items are deleted

/**
 * Delete the given Field from the given Page
 *
 * @param Page $page 
 * @param Field $field Field object
 * @return bool True on success, false on DB delete failure.
 *
 */
public function ___deletePageField(Page $page, Field $field) {

    $result = parent::___deletePageField($page, $field); 
    $this->deletePageField = $field->get('parent_id');
    $fieldParent = $this->wire('pages')->get((int) $field->get('parent_id'));

    // confirm that this field parent page is still part of the pages we manage
    if($fieldParent->parent_id == $this->repeatersRootPageID) {
        // locate the repeater page parent
        $parent = $fieldParent->child('name=' . self::repeaterPageNamePrefix . $page->id . ', include=all'); 
        if($parent->id) { 
            // remove system status from repeater page parent
            $parent->addStatus(Page::statusSystemOverride);
            $parent->removeStatus(Page::statusSystem);
            $this->message("Deleted {$parent->path}", Notice::debug); 
            // delete the repeater page parent and all the repeater pages in it
            $this->wire('pages')->delete($parent, true); 
        }
    }

    return $result;
}

As for your second question, I wouldn't worry as long as everything works fine

[quickjeff]

Awesome thanks for explaining it. I never seen that. However, everything seems to be working. just didn't want to get 1000 pages in and bam it breaks. this is going to be a big site and already exceeding 500 pages. 

[abdus]

14 minutes ago, quickjeff said:

just didn't want to get 1000 pages in and bam it breaks. this is going to be a big site and already exceeding 500 pages. 

No reason it would break at all. It's quite robust and a lot of corner cases are handled in the module source. But, regardless of your setup or page count, make frequent backups of your DB.

http://modules.processwire.com/modules/cronjob-database-backup/