adrian

That sounds like the key issue in all this to me - very good point! And Pete - thanks for those links. Lauren will have some thinking to do when she finally gets back to this thread

Thanks to the three of you for you work on this! Can't wait to test - will definitely be using it on a new site that is starting dev in the next couple of weeks. I'll let you know how it goes!

Thanks Pete - I am not sure about the effect of removing StopWords on SEO either, but seemed like a nice quick module to whip up so thought I'd help out Actually I have just revised the module. The first iteration completely overrode the InputfieldPageName.sanitize method. This new version just adds and applies a new method for removing the stopwords. This should be much safer in that we don't need to worry about overriding any updates that are made to that method in the PW core. New version attached in my post above.

Hi Lauren, I have thrown something together for you. It isn't well tested yet, but seems to be working fine. You can edit the StopWords.js file if you want to adjust the words that are removed. If there is general interest in this module, I might consider making it configurable. Let me know how it goes for you. PageNameRemoveStopwords.zip

Ok, v3 takes care of populating the description fields for the new image pages. The one thing I don't like about all this is the duplication of the image files themselves. Maybe the module should delete the original images after the child pages have been created?

I think I know what you mean - I have just committed an update that will use the entered description for the title of the page is it is entered - otherwise it will fallback to the filename. Is that what you meant? The code was quickly put together, so I expect the OP may want to tweak other things along those lines - should hopefully be a good starting point though.

Hi Lauren, You'll need to hook into ProcessPageAdd::buildForm and potentially ProcessPageEdit::buildForm if you also want to change the name when the title is changed during a later edit. You can get an idea of how to do this from my Page Rename Options module (https://github.com/adrianbj/PageRenameOptions/blob/master/PageRenameOptions.module#L65) You can see that I have added some JS to override the native functionality when it comes to naming the pages. You will be looking to add to/override the functionality in these files: https://github.com/ryancramerdesign/ProcessWire/blob/6cba9c7c34069325ee8bfc87e34e7f1b5005a18e/wire/modules/Inputfield/InputfieldPageName/InputfieldPageName.js https://github.com/ryancramerdesign/ProcessWire/blob/6cba9c7c34069325ee8bfc87e34e7f1b5005a18e/wire/modules/Inputfield/InputfieldPageTitle/InputfieldPageTitle.js Hope that helps to get you started. There is nothing wrong with messing with the page name - in fact it is possible to manually edit it by hand. The one thing that some don't agree on is whether it should ever be changed after it is originally created. I would personally rather the name matched the title, but others think it should never change due to SEO and broken links. I make use of the Page Path History module to deal with these - maybe not perfect, but typically the only time the titles will change is during development, so I am ok with it.

Hi @paulbrause, Lots of great suggestions above regarding PageTable fields etc, but I just put together a quick module that I think does exactly what you are looking for. https://gist.github.com/adrianbj/2b3b6b40f64a816d397f To make it work as is, you will need these: Templates: album (for the album parent pages) image (used for the automatically created child pages) Fields: images (for the album template) image (for the image template)

Thanks Pete - it's been fun to work on I'll update the Readme to detail the new features and merge all the changes shortly.

Very glad it is working for you as expected. But I am curious what, if any changes you made. Did the Github issue fix itself? What about the missing zip/json error - was that just a result of the exit code commenting? Is there anything else I should know about? Thanks again for your extensive testing - did you ever figure out anything around that serialization error?

Instead of this: } else { $nunya = $pages->get("/http404/"); $session->redirect($nunya->url); } do the following: else { throw new Wire404Exception() } Same of course also for the segment2 check

The Load option should do exactly what you are looking for. You shouldn't have the /sales/listings at the beginning of the rewrite format - just use: /{$page->make->name}/{$page->model->name}/{$page->id}/ I haven't tested thoroughly with adding extra path segments like you are doing, but it seems to be working fine here. Typically I just put dashes between the components. Glad you sorted out the include_once issue To get the View links when editing a page to also be rewritten, make this change to line 115: if($page->id!=1 && $page->template != 'admin') { to: if($page->id!=1) { I did a quick test and I don't think there are any issues with this, but would appreciate you testing it before I make it live.

You can use a simple helper module to rename a page to its ID. You can find the techniques required for that in this thread: https://processwire.com/talk/topic/1648-ok-to-change-page-name-path-after-save/?p=15232

Does anything in this thread help? https://processwire.com/talk/topic/5083-possible-bug-page-fieldtype-with-custom-selector-to-find-selectable-pages-returns-error-while-saving-page/

The easiest way to do that is: $fieldsToIgnore = array('title'); $fields = $refPage->getInputfields(); foreach($fields as $f){ if (!in_array($f->name, $fieldsToIgnore)){ $form->append($f); } }

Most likely the only issue is that PW variables like $page are not available inside functions due to PHP variable scope. If you replace $page with wire('page') is should work just fine. That said, this is why page fields are a better approach than this module for anything but the very basics (which it is great for!) when it comes to select type fields

Antti put this out some time ago now: http://modules.processwire.com/modules/inputfield-flickr/ Back to topic - happy new year to everyone - my current backyard is the view in my avatar

I just tested that code and it is working fine here. Have you checked that the Add New button actually works for the page table field. Make sure there are no errors like template not allowed or anything else wrong with the page table config setup. Do you have debug mode turned on?

Some other good tools for batch creation/editing: http://modules.processwire.com/modules/process-batcher/ http://modules.processwire.com/modules/batch-child-editor/

Sepiroth - I moved your post here, because all those relate to Migrator. The first one regarding Github is surprising - perhaps they were down momentarily. Please let me know if you continue to see that one. The serialize error is also a mystery to me - I see it occasionally when I use Migrator - it seems to be random and it doesn't seem to affect the import process. I don't do any database serialization in the module at all. I need to investigate further at some point, but I think for the moment it can be safely ignored.

You'll probably want: if($user->hasRole("viewer")) Note the quotes around the name "viewer", rather than $viewer But otherwise, that should do what you want!

Whatever! Very far from it - sometimes we all just need a second set of eyes

Can you send through the entire code for your form - I'd be happy to test and figure this out for you - would be good to know if it's new PW bug.

I am a big fan of Forklift for remote editing (although I am sure many others work well). The great thing about Forklift is that it is a full dual pane Finder replacement. I honestly couldn't survive without it. Finder really is horrible http://www.binarynights.com/forklift/

I found the problem You are overwriting $field so the value of $field->columnLabelFieldName is blank. This line is the culprit: https://github.com/kongondo/FieldtypeMatrix/blob/master/FieldtypeMatrix.module#L168 foreach(wire('fields') as $field) { If you log $field->columnLabelFieldName before that, it returns the selected value as expected. Hope that helps!