thetuningspoon

@Robin S Great, I'll try it out. Does this also mean that textareas are a configurable input type now? That was a feature I was going to request.

The close button is working now, but opening an existing code now shows a completely blank iframe in the popup. PW version is 3.0.40. Hanna code is 0.2.0 Edit: No console errors, either.

Hi Robin, Great module. Is the module dialog supposed to allow you to edit existing Hanna Codes? When I double click an existing code, it opens in the dialog but none of the inputs are filled out. If I save, then all of the content disappears. Another issue I ran into after upgrading to the latest build: The cancel button on the dialog no longer works. The JS error I'm getting is: "hannadialog.js?t=2015030801.157:32 Uncaught TypeError: Cannot read property 'setAttribute' of null"

YES. YES. YES. I can't wait to try this on my latest project

Hmm... But #2 isn't required, it's only one of the conditions under which the file access will be blocked, so I still don't get it. I think I will post on GitHub.

Thanks very much, Kixe. Good call on the before hook. Maybe you can help me better my own understanding of the situation... I guess I am still not understanding a piece of the puzzle here. Consider the following: $config->pagefileSecure is set to true Page::isPublic() returns false User is not logged in If all 3 of the above are true, the file should not be directly accessible... correct? This is how PW behaves normally, with no need to hook ProcessPageView::sendFile(). Yet when all of the above is true except that Page::isPublic() was modified by a hook, suddenly it doesn't work as expected. There must be some other requirement that isn't being met, since this functionality doesn't normally require hooking sendFile(). See what I'm getting at?

Why does sendFile() send the file even if isPublic() is false?

Right, except that it doesn't - This is the part that isn't working right. Are you saying that the prefix would be removed after saving the page? I thought that it would be added after saving the page. Why would the directory be renamed as long as isPublic() continues to return the same value?

I don't actually want to replace the method entirely, just change the result under some circumstances. But the hook clearly is working, it just doesn't look like it's running early enough, perhaps. Thanks for the debugger suggestion... I am working on getting a proper debug setup going.

@kixe In your ProcessPageView::sendFile hook, are you checking Page::isPublic first? The way you have written it, it would block all files. Should I submit a report on GitHub? It seems like the isPublic hook should be enough to make this work. I don't understand why it isn't honoring it. Edit: Does sendFile() actually get called when a file in the assets folder is accessed directly?

Just tried it in init.php... No go.

Hmm, I didn't realize that init.php existed. However, I think that I tried the hook in the init() of one of my modules and I don't think that worked either. I ran out of time and had to try a different approach, so I'll have to revisit this later.

I have a secure area of my site where I need protection against direct access of files in the /site/assets/ folder. I have enabled $config->pagefileSecure. After some research, I discovered that the Page::isPublic() method is what controls whether ProcessWire secures the files or not, and that this is determined by whether or not the template has guest view access. However, I do not want to have to disable guest viewing inside the ProcessWire template, since I want my customer to be able to control this on a per-page basis. (In fact, I want the page to load even for guests so that I can display a login form on the page in place of the content). I have created a password_protect checkbox on each page, and want this to determine whether the content gets displayed and whether or not the files get secured. I created the following hook in /site/ready.php: $this->addHookAfter('Page::isPublic', function($e) { $that = $e->object; $public = $e->return; if($that->password_protect) $public = false; $e->return = $public; }); If I check $page->isPublic() inside of my template, it correctly shows as false. However, the files are not being secured. For some reason it is not effecting pagefileSecure. Any idea what I'm doing wrong?

Thank you LostKobrakai, I guess it makes sense that PW would include the access restrictions in the SQL to avoid getting the pages from the database in the first place. I didn't know about DynamicRoles (or maybe I did and then forgot). It looks very interesting. I cannot keep up with everything going on with PW any more (not sure if that's a good thing or a bad thing!) I will probably just use the viewable() check manually for now. It does seem to work in every case (admin page tree, actually trying to access a page) other than find() operations.

I am hooking after Pages::viewable() to add a per-page permissions control based on the state of a field I've added to each page. The field is a Page field which lets you choose which role(s) the page will be viewable for. The hook is setup in the init() method of one of my modules. In one of my templates I am using a $pages->find()->children to get some pages and looping through them to output a list. If I check for $item->viewable() before outputting each item, it only outputs the ones that are viewable by the current user (GOOD!). However, if I do not explicitly check with viewable(), all pages are shown (BAD ) I figured that $pages->find() must be using the viewable() method internally to determine which pages to return, so that my hook would be called (unless check_access=0 is used in the selector). But that doesn't seem to be the case. Am I wrong about find() using the viewable() method? Or is my hook maybe getting added in the wrong place?

I guess I always found it strange that there was a rootParent property, since the determination of the rootParent as the 2nd level parent page seems a bit arbitrary and opinionated compared to most of ProcessWire's very un-opinionated API. I think the level could come in handy in many cases, though admittedly I can't name them off the top of my head! I know that I have had several use cases for this in the past where I've had to do the $page->parents->count() trick. I think being able to search for a page something like $pages->find('template=folder, level=2') could also come in handy, though I assume this can also be achieved now with $pages->find('template=folder, parents.count=2') now (though I haven't tested that). It would just be a lot clearer for non or newbie-programmers to realize the capability is there. Edit: One common place where the level property could come in handy is building menus as well as determining whether to show a submenu on a page or not. Generally this should be based on your depth in the page tree rather than on the template or a field setting.

Thanks for the more compact version, LostKobrakai. I didn't get enough sleep last night so my code was probably a bit sloppy. I still haven't thoroughly tested it either.

I am trying to do something similar to a $page->rootParent check, but for a site using Soma's multi-site module. Because the "roots" for a multi-site are actually the 2nd level pages rather than the first level, this means that $page->rootParent doesn't give me what I need to check which "section" of the site I'm currently in. This made me wonder, shouldn't there be a simple $page->level or $page->depth property that returns how deep any page is located in the page tree? Then we could do things like $page->parents('level=2') to get a parent at a specific level, $page->level to determine whether to show/hide some element in a template, or $pages->find('level=2') to get all pages at a certain level. I built some hooks to add in this functionality, although it won't work for database selectors: /** * level * * @return int - Level/depth of this page in the page tree */ $this->wire()->addHookProperty('Page::level', function($e) { $e->return = $e->object->parents->count(); }); /** * parentLevel(int $level = null) * * @param int $level * @return - Returns the Page's parent page at the requested depth/level in the page tree. Returns NullPage if there is no page at that level */ $this->wire()->addHook('Page::parentLevel', function($e) { $that = $e->object; $level = $e->arguments[0] ?: null; if($level == null) $e->return = new NullPage(); else { $parents = $that->parents->append($that); if($parents->count() < $level) { $e->return = new NullPage(); } else { $e->return = $parents->eq($level); } } });

https://github.com/processwire/processwire-issues/issues/87

I just converted all my code to use the string format instead and it is working, so this seems like an issue specific to the array format.

I tried a lot of things, so I'm not 100% sure... but I think that I did try that. Let me give it another shot as a string.

Are nested selectors compatible with the new array format for selectors in PW 3? I am trying to find all pages ("Tours") that have at least one child ("Departure") that matches my conditions. This is the only way I could get it to work (simplified for readability): // Build the Tour selector based on the our filters $selector = []; $selector['template'] = 'Tour'; $selector['sort'] = 'Title'; // Select matching Departures so that we can narrow down the Tours further $startDate = $this->input->get->start_date ?: date('Y-m-d'); // Never show tours without any upcoming departures scheduled $startDate = \DateTime::createFromFormat('Y-m-d', $startDate)->getTimestamp(); $departureSelector = []; $departureSelector['template'] = 'Departure'; if($startDate) $departureSelector['departure_date>='] = $startDate; $departures = $this->pages->find($departureSelector); $selector['children'] = $departures->getArray(); // Only include Tours with at least one matching departure $tours = $this->pages->find($selector); // Run our completed selector I initially tried putting the $departureSelector directly into the $selector['children'] element, but this would only return a single match. Then I tried running a separate find() on the $departureSelector and putting that into $selector['children']. Same result. It wasn't until I called getArray() on $departureSelector to convert it to an array instead of an object that it worked. I'm assuming (perhaps wrongly) that the additional find operation is less efficient than a real nested selector, so I would much rather use a nested selector. Is this a bug in the new selector arrays implementation, or am I doing something wrong?

You would have to have some Javascript/jQuery to search the DOM for a pageTable row that uses that template and then add/remove the disabled attribute from the corresponding add new button. However, I'm not sure if the page template name is actually output anywhere in the table row or not. If it isn't, then you'd probably need to use a php hook to add it in. Or you could pull the page ID and use AJAX to check which template that page uses

As others have said, you have to retrieve the page first. Also, it might have just been a typo here, but don't forget the "$" before your variables!

@BitPoet Wow, this is perfect timing, as I am just working on the requirements for a project that requires storing a lot of JSON. Does this enable storage and retrieval of nested JSON content that is multiple layers deep? E.g. $pages->find('jsonField.subField.field=foo') ? Obviously this would present some challenges for displaying the data on the back end using your current tabular format. Maybe a nested list (like ProcessWire's page tree) would be a more scalable approach?