Neeks

Updated the module to to fix the following issues: - missing $sTable variable warning in debug mode. - module now requires you to have PagePathHistory module installed - I simplified SQL, hoping that got rid of the SQL errors, though I could not reproduce them. - remove trailing slashes on "redirect from urls" since PagePathHistory requires them to be missing for redirects to work.

This module both lets you create new redirects that never existed, and delete old redirects one would no longer like to have operational any more. The user story for this project was: "As an SEO specialist I want to be able to manage redirects for news articles without developer involvement." Giving them a simple tool that did not require knowledge regex seemed like the safest way to not have future developer involvement.

Page Path History Central Manager Manage all page paths history redirects in a single locations. This module is user interface for the processwrie PagePathHistory module, that creates redirects automatically every time a page is moved/renamed. These redirects do not contain regex's and they will not redirect a user away from a published page making them safe for not technical editors to create. Features Include: Ability to create new redirects Ability to remove old redirects View all the automatically created page path history redirects in your system, and delete any ones that no are no longer needed. Git repo: https://github.com/hagcin/ProcessPathHistoryCentralManager Viewing all existing redirects: Adding New Redirect: Tested on: Processwire 2.6, 3.0 Install Install the module PagePathHistory from within the Processwire admin. PagePathHistory is included in core but not installed by default. Install the module ProcessPathHistoryCentralManager by cloning this repo into site/modules/ in your processwire install. Install the module in the admin interface. You can now manage redirects under setup > page path history central manager Similar to and is compatible with PagePathHistoryManager which lets you manage page path history redirects on a specific page on the settings tab.

Tything to get the processwire version 3 of the module working correctly. Admin: Data Providers Name Space : "pwire\DataProviders " Data Provider Base Path : "site/templates/dataproviders/" site/template/home.php (template) site/template/dataproviders/pwire/HomePageDataProvider.php (data provider) namespace pwire; class HomePage extends \nw\DataProviders\PageDataProvider { public function populate() { echo "you made it here "; die(); } } Do I also need to any something to my composer file to get the class to autoload, or just put it in the correct directory?

created an issue, thanks.

Bug report: When adding the permission "page-publish" , and logging in as a user that does not have that permission, the publish button will be removed, but only part way, and a set of links belonging to that button will still show. System: Clean install with pro drafts, and croppable image 3. ProcessWire 3.0.62 Browser: Safari Use Case: Setting up a workflow where users can draft pages, but not publish them. (so that all content can be reviewed first)

The one module I didn't uninstall because it was so simple it could not possibly break anything was causing the problem. Added a name space to the module, and everything works like magic. I think the module compiler just had an issue that that module for some reason. Thanks for suggestions.

This one has me stumped. When I login into the admin with any user but a super user I get this error: Unknown Selector operator: '' -- was your selector value properly escaped? field='Array', value='', selector: 'Array, parent_id=31, templates_id=5 Parent=31 is the Admin > Access > Roles page templates_id=5 is the permission template Other than that I have so idea why selector is showing up empty and crashing the site. I have uninstalled almost all the none-core modules in my system. Full Stack trace: Notice: Array to string conversion in /home/www/processwire/wire/core/User.phpon line 203 Warning: Illegal offset type in isset or empty in /home/www/processwire/wire/core/Permissions.phpon line 83 Warning: Illegal offset type in isset or empty in /home/www/processwire/wire/core/User.phpon line 219 Notice: Array to string conversion in /home/www/processwire/wire/core/PagesType.phpon line 283 Notice: Array to string conversion in /home/www/processwire/wire/core/PagesType.phpon line 287 Warning: strpos() expects parameter 1 to be string, array given in /home/www/processwire/wire/core/PagesType.phpon line 301 Notice: Array to string conversion in /home/www/processwire/wire/core/PagesType.phpon line 158 Warning: strpos() expects parameter 1 to be string, array given in /home/www/processwire/wire/core/PagesType.phpon line 159 Notice: Array to string conversion in /home/www/processwire/wire/core/PagesType.phpon line 169 Fatal error: Exception: Unknown Selector operator: '' -- was your selector value properly escaped? field='Array', value='', selector: 'Array, parent_id=31, templates_id=5' (in /home/www/processwire/wire/core/Selectors.php line 396) #0 /home/www/processwire/wire/core/Selectors.php(439): ProcessWire\Selectors->create('Array', '', '') #1 /home/www/processwire/wire/core/Selectors.php(159): ProcessWire\Selectors->extractString('Array, parent_i...') #2 /home/www/processwire/wire/core/Selectors.php(145): ProcessWire\Selectors->setSelectorString('Array, parent_i...') #3 /home/www/processwire/wire/core/PagesLoader.php(217): ProcessWire\Selectors->init('Array, parent_i...') #4 /home/www/processwire/wire/core/Pages.php(232): ProcessWire\PagesLoader->find('Array, parent_i...', Array) #5 /home/www/processwire/wire/core/Wire.php(386): ProcessWire\Pages->___find('Array, parent_i...', Array) #6 /home/www/processwire/wire/core/WireHooks.php(698): ProcessWire\Wire->_callMethod('___find', Array) #7 /home/www/processwire/wire/core/Wire.php( in /home/www/processwire/index.phpon line 64

Just want to give a big thanks you to the processwire team! And all the hard work that has gone into the PW this year! Really grateful for how well this project has been developing and how much thought and handwork goes in behind the scenes. I am really looking forward to those native import / export features! As far as JavaScript rest $page API's goes you might also want to look into a GraphQL implementation, it seems like an ideal way to cut down on the network chatter for headless CMS's, and is becoming an emerging standard. also see:

I'm finding a compatibility issues with CroppableImage and ImagikResizer/PageimageSizerImagick V0.31 plugin. I am wondering if any one else is having issues? The Issue: When both plugins are installed croppableImage stops working properly. It will crop the image but always in the center, and ignores the selection tool that lets specify what part of the image to crop from. Versions: Processwire: 2.6.0 PageimageSizerImagick: 0.31 CroppableImage: 0.84 Note: I wanted to try to put in an issue on the Git page, but it is 404ing right now. https://github.com/horst-n/PageimageSizerImagick

What would be the best way to add an existing field right before the ending of an existing feildset? IE. I already have a fieledset called seo and I want to add a field right before the closing for "sitemap_ignore" via the API.

Amazing work with this module. Image magik is light years ahead of GD in terms of how will it sizes PNG files. Especially logos where you need to see hard clean lines. I have noticed that of the 30 logos I have sized with image magik 4 of them came out looking like this. if I save the file again in photoshop it totally fixes the issue. might be the images have some kind of bad data that only image magic picks up and GD doesn't? Or it might be the module...I just wanted to bring it to your attention, just in case it's helpful. Here is the original: Again, amazing module!

Solved it by reading how $pages->clone() does it, and just doing that.... I also see that $pages->clone() has the ability to set an argument to specify a page ID which solves my issue of cloning a page and not having the the page ID I want after the clone. //copies the fields of one page to replace the fields of another page. function copyFields ($sourcePage, $destinationPage) { //Copy Fields between pages $destinationPage->of(false); $sourcePage->of(false); foreach ($destinationPage->template->fieldgroup as $field){ if($field->type instanceOf FieldtypeTable){ //You get duplicare SQL index errors if you don't use clone. $destinationPage->$field = clone $sourcePage->$field; }elseif($field->type instanceOf FieldtypeTextarea){ //Update image an file links in rich text fields $destinationPage->$field = str_replace("/files/{$sourcePage->id}/","/files/{$destinationPage->id}/",$sourcePage->$field); }else{ $destinationPage->$field = $sourcePage->$field; } } // Copy $sourcePage's files over to new page if(PagefilesManager::hasFiles($sourcePage)) { $destinationPage->filesManager->init($destinationPage); $sourcePage->filesManager->copyFiles($destinationPage->filesManager->path()); } return $destinationPage; }

I want to copy all the content from one $page to another $page. The use case: To create drafting workflows. The contents of one page needs to be copied to replace another. The problem points: images and files don't copy with my current approach. So far it looks like you have to: copy the files /assets/your-page-id/ to /assets/your-new-page-id/, then do a search and replace on any Rich Text Fields fields that contained the paths for those images. (easy search and replace) Are there any system tools for migrating images and files from one page to another. It seems like clone does this all automatically. I would love to leverage existing tools if they exist before trying to build my own. Also I wonder if this is the correct way to copy the non-filesystem based data : $pageA->image = $pageB->image; $pageA->save()? Method #1: for copying fields from one page to another: (thanks to some tips from Soma, it works great, but does not yet work on image fields, or files) public function copyFields ($sourcePage, $destinationPage) { //Copy Fields between pages $destinationPage->of(false); $sourcePage->of(false); $debugMsg = ''; foreach ($destinationPage->template->fieldgroup as $field) { if ($destinationPage->$field != $sourcePage->$field) { $destinationPage->$field = $sourcePage->$field; $debugMsg .= $field . ","; } } $this->message("Fields Copied: $debugMsg", Notice::debug); return $destinationPage; } (If there are any system tools for dealing with, the migration of images and files from one page to another id love to learn about them, even if they are low level like "the process wire method for creating asset folders, and copying files" if such functions exist...otherwise ill use the basics.) Can't you just clone the page? I tried cloning the page. It works AWSOME!!! except! I am unable to transfer the ID from the page being replaced by the clone, to the clone. When Id's Change page relationships can break. While clone works awesome at copying data between pages, not being able to change the ID of a page post clone, makes me think it might not be a viable option for copying data of one page with another. If any one wants to look at my simple method for replacing a page with a clone and offer a suggestions... Method #2 Cloning a draft page to replace original content page private function pushDraft ($draft) { $page = $this->getSourceFromDraft($draft); //Backup important fields before we delete our Original page. $pageOriginalParent = $page->parent; $pageOriginalName = $page->name; $pageOriginalId = $page->id; //store revision history on draft page just so it does not get deleted $this->movePathHisory($pageOriginalId, $draft->id); //delete original page wire('pages')->delete($page); //Clone a copy of draft to replace original page //we save a copy of the draft page and original page else where in case we need to revert. $replacementPage = wire('pages')->clone($draft, $pageOriginalParent); $replacementPage->name = $pageOriginalName; $replacementPage->id = $pageOriginalId; //This is the part that does not work as It might. //The assignment happens in memory but not in the database of file system on save. //there might be a really good reason for this though, I don't imagine people need //change page ids that often. $replacementPage->save(); $this->moveRevisionHistory($draft->id, $replacementPage->id); return $replacementPage; }

@Teppo, thanks for confirming that is how it should work...I stepped away from my code and tried it with straight SQL and with hard coded page ID's and it worked. I did try this earlier, but I must have been working with not enough sleep (I was on the wrong server writing SQL and watching for results in the admin of another...sigh...)