Soma

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.

Wel Welcome sosoba! This would be possible by making a hook to any of the the form building methods in ProcessPageEdit.module. All methods with three underscores are hookable. All about hooks. Take the HelloWorld.module and add this hook to the init() $this->addHookAfter('ProcessPageEdit::buildFormSettings', $this, 'buildFormSettings'); And then add this function to the class. public function buildFormSettings(HookEvent $event){ $fieldset = $event->return; // get the fieldwrapper returned $field = $fieldset->get("_pw_page_name"); // get the name field $field->collapsed = Inputfield::collapsedYes; }

It's not possible to help without seeing your code. $event depends on what you hook. Theres a comprehensive new docu by Ryan on the API section.

This modules isn't aware of those setting as it uses it's own process to get and render out the pages. I know it can be implemented and where, but it's not that simple as I'm also not aware of all settings and effects this would have... I would consider using the new LanguagePageNames, which for sure will work in those cases. It's still in beta, but so is this module and not sure we're going to further maintain this module because it's now in core what this module implements.

The $page var in the custom PHP field is "broken" in 2.3 as it doesn't return the page edited anymore but the process page edit. I just got a problem with this yesterday when updating a website to latest PW. I fixed it by using $_GET['id'] to get the id of the page being edited. $p = $pages->get($_GET['id']);

Maybe Ryan was doing something, or it's again the caching from github page. Ryan setup a PW installation I've done to manage the cheatsheet in future. It's available here http://cheatsheet.processwire.com/ Or on github page http://somatonic.github.io/ProcessWireCheatsheet/

Some interesting reads for those interested in security: Well it should be mandatory for every webdev to know these thing or at least care about. Hack yourself first - how to go on the offence before online attackers do http://www.troyhunt.com/2013/05/hack-yourself-first-how-to-go-on.html Feel free to discuss or post other articles about the subject.

Yeah it's not (yet) on the Cheatsheet. No it does grab the pages by id as the name indicated ProcessWire never does grab the "whole" pages unless you need it or a field is autojoin. It's kinda lazy loading.

Well that doesn't really come through until now... So what now? If all of the "list" are in the PageArray (but also some others), or if the PageArray is the list 1:1... ? Now I'm curious why you want or need that? I would do that if you want to test if all of the list pages are in the PageArray: $result = $pages->find("template=basic-page"); $list = $pages->getById('1001,1002'); if(count($result->filter("id=$list")) == count($list)){ echo "all found"; }

A german presentation about ProcessWire: Video: (second half is PW) https://bambuser.com/v/3588985 Slides: http://wdcmdresden.github.io/treffen/24-knockout-und-processwire/processwire/#/

That's what I assume he wants... If you want to know which is in the page array use filter. $found = $pageArray->filter("id=1001|1003|1005"); echo $found; // 1001|1003