Soma

If you use PW form API, it will get validated if you call processInput() $form->processInput($input->post); I think the CSRF doesn't get reset if the CSRF was valid, but you can do it manually with $session->CSRF->resetToken(); after validating the form. Or if you do manual form and not use InputfieldForm you can generate and validate the token $session->CSRF->validate(); // will throw exeption if invalid And get the token name and value with it respective methods $session->CSRF->getTokenName(); // name for input hidden $session->CSRF->getTokenValue(); // token value Also the trick renobird mentioned is also very good to prevent double click submission errors. Of course you can still use redirect method and as you may found the $notices errors and messages are transported through redirects.

I implement the PW CSRF token in my forms so a resubmit will result in a error message.

Those permission hooks are in PagePermissions.module, and they're defined using hooks, so there's no methods ___viewable.

Yeah this is the module from that thread. Yes it's for page-view, but I just thought it could be extended for page-edit too... as mentioned in the thread that it's a start. Yeah another way of doing, but it would be nice to have one that does it all, instead of many that only do partial.

Thanks for sharing pogidude. Are you ware of this module? http://processwire.com/talk/topic/371-page-specific-permissions/?p=2787. This might would have been a good starting point for this module.

Just use isset($input->post->list)

You can use ModulesManager to download/install modules already. I have no idea what this error is about, looks like some server configuration issue?

PW installer does this if it can.

Thanks diogo for testing. Then it seems you also run into a problem with permission locally. If it didn't rename the htaccess file when manually copying PW files it's because apache user and your local user are not the same (along these lines). I think I experience the same, but I changed some permission for apache to run as my user and it also works manually now. Edti: I just updated the script to also remove the zip and script when everything is done.

ProcessWire Online Installer Since there's now a shortcut to download latest stable PW http://grab.pw , I created a simple helper PHP script you can upload to your server to download and extract a new PW installation. Upload this php file to the server where you want to install latest ProcessWire Go to the browser and call this script. It will download and extract ProcessWire files. Once done successfully it will redirect to the installer. Downloaded zip the grabpw.php will be removed. If anything fails, make sure permission are correct on server and you remove files manually in case. I tested this on my local XAMPP (Mac) install and on some of my account on a ISP. Also I took some methods to download and extract files from my ModulesManager which seems to be "reliable" so far. Download The script can be found on github: https://github.com/somatonic/PWOnlineInstaller Why Just because it's cool. There's many ways to accomplish this task if you have ssh access for example using shell. Just wanted to have this alternative and maybe people find this useful too. @ryan. Do you think you could provide an latest dev shortcut url too?

Have you cache enabled?

I'm not getting it completely. Do you mean if you enable some output formatting on the date field it outputs wrong date?

Codemagic is even in the core tinymce plugins in PW. Just have to add it in the field configuration. It even has hightlighting and search replace and autocomplete.

To defend ImagesManager. You can select the tag to insert... and you can still use the image dialog to insert.. And also it will let you upload and track images even if you change location or image itself..

You may want to look at my ImagesManager. https://github.com/somatonic/ImagesManager/blob/master/ImagesManager.module#L509 Thing is if you upload image and attach it to page with $page->image->add(path.jpg) the max dimension won't be executed since it's not a PageImage object. I worked around that by creating the PageImage first and adding that.

The output format is for the formatting on when you output in templates, has nothing to do with HTML5. THe inputfield for datefield in HTML is only very partly (chrome) supported and don't think it's a good thing for PW backend as it would inteferer with the native datepicker.

Are you gone crazy? And even with colors!

Nicely said Ryan! I wonder why always people with "I only know basic HTML and CSS" come with the biggest and most complex coding PHP projects that even an experienced developer would have its adventure.

Here's another idea to have a flag on the authors page you would keep track if there's any books of the author. So a simple module that does the following on book page save $authors = $pages->find("template=author"); foreach($authors as $author){ $found = $pages->count("template=book, authors=$author"); $author->of(false); if($found && $author->has_books == 0) { $author->has_books = 1; $author->save('has_books'); } else if($author->has_books == 1){ $author->has_books = 0; $author->save('has_books'); } } After that you can simply use: $authors_with_books = $pages->find("template=author, has_books=1); Of course if you have a lot of authors it may not as efficient. But it could be more optimized using a direct SQL then.

Yes, it was more of a proof of concept, but it's working fine. You just have to enter the template and fields of both ends in the module and it will take care when page is saved and map both ends.

Well ok, it makes sense, but you seem to want to list authors and not books? So you can't use simple selectors and have to fall back to use SQL to query them for which have books and maybe how many. No big problem, either way you can run into not being able to use PW selectors. Just was thinking out of the PW page "editing" context for a moment. I once wrote a two way relation page field module that you would have selects on both author and books and when changing one side the other will update, this way you can run simple PW query on both sides. (not saying you should use this). My example code isn't a problem and is the most simple way in that case.

I would do a relation the other way around, have authors reference their books. Isn't it? Otherwise a trick could be used to when saving the book page to save a flag to the author selected, but as I said the "DB" design you have is wrong. I don't think there's books without an author. Edit: It could be even flat hierachy, have the books as children of authors. Pretty easy, unless you need multiple authors per book.

I don't think it's a big problem looping all author, I think you won't have thousands anyway? No it's not possible with a single selector, only the other way around. An optimized query would be using direct SQL, and could be well made into a helper module. Example: (removed) Edit: just realized it's not exactly what you want, need to adapt a little This will give you pages that have a reference to them via the defined field and are published: $pagefield = "select_page"; $query = "SELECT p.id FROM pages p RIGHT JOIN field_$pagefield b ON p.id=b.data WHERE p.status < 2048"; $res = $db->query($query); $ids = array(); while($row = $res->fetch_array()) $ids[] = $row['id']; $pa = $pages->getByID($ids); foreach($pa as $p) echo "<p>$p->title</p>";

Yeah the naming is done by the PageImage I think.

Ok since you hook Page::viewable every page in PW will be somehow affected, even admin pages as they are also just pages. So the message with $event->object->name is the admin pages rendered in the admin template. I'd guess it's the navigation. But since the ProcessPageList module is ajax driven you won't see any messages from there. $event->arguments is nothing there I think, as the important with these page access hooks is the $event->return value. So you would do set it to false or true $event->return = false; // page won't be viewable All the viewable hook does is define if a page is viewable or throw an 404. In case of the admin page tree the page will still be visible and only have no -view- action button. That's all. If you really want to hide pages in the admin I'm with Ryan, but see that there's cases where it would be nice to hide pages from users and keep a branch hidden from them. I already stumbled and tried very hard 1-2 years ago, but realized it's not easy as there's no obvious hooks available where needed and it's done with ajax and there's some things to consider, didn't really bother. Now after thinking for some time and try error I found an easy way to just remove pages from the page list tree. The trick is to modify the JSON output that goes with the ajax response, convert it to an array and Long story short here's an example module for those interested. I used a pagelist_hidden page field added to the user template to define pages that are hidden for a user. Of course there could be endless configuration possibilities, with roles and what not, but don't want to go any further and maybe someone else finds this useful or as a start for a new module. If Ryan reads this and is still with me. Would you consider adding some hooks to ProcessPageList.module? Or do you think the JSON manipulation is a good way? Most likely there would have to be some additional take care to make those pages also not editable. Those page will still be accessible manually through admin url. Such a module shouldn't be used to hide pages for access restriction, and it's only and best suited for hiding "private" branches in the admin, or functional pages that can't be in the /Admin/ branch for some reasons.