Leaderboard

@Lars282 Soma and Slkwrm have it right. Keep in mind that saveReady is called after it's been confirmed the save() will definitely occur, and right before the save actually occurs. So this is the ideal hook for you to use in your case. This is correct. We don't yet have a property $page->statusPrevious property like we do for parent or template. So there's no way for you to know what the previous status was short of loading another copy of the page, or just querying the database like in the example. But now you've got me thinking I may need to add a statusPrevious property in a future version. For your hook attachment code, I would suggest this: public function ready() { $this->pages->addHook('saveReady', $this, 'sendMailOnPublish'); } …basically the same as what Soma suggested, except that I would add it to $this->pages directly since there is only ever 1 instance of $pages, making it slightly more efficient to do this way. Your actual hook function will be in the same class as your ready() function, and would resemble the one Soma posted. This is correct. If there was no $page->id, it would be a new/unsaved page, and you wouldn't want to go querying the DB for it as we know it wouldn't be there. So that's what the $page->id check is for.

Your problem got solved a while ago, but a bit of information was left missing: the actual reason your code didn't work as expected. The original version is a bit complex, yes, but it's actually only a single ampersand away from working. (Well, I didn't read the output carefully through so there could be some other flaws as well). The problem is that $output is being passed by value to sub() when it needs to be passed by reference for sub() to be able to change it. So changing the function definition to "function sub($page, &$output)" does the trick. More on passing by reference for example at php.net article (not so good a reference though). But this is just to point out what was wrong in the first place in case someone was left wondering, as the code may seem right at the first glance. Of course you could modify it a bit in another way as well (returning the $output and assigning it back to where it belongs would work too) but let's leave it here as better solutions were already given by Soma more than a week ago .

I agree that something like drop-down "Actions" menu would be useful. And maybe some new hook, for example, "___actionButtonsRender".

I wonder seeing so many image modules popping out, the image fileld gets clutered. Would make some way to make this streamlined? Like a place or method to be able to add actions. I don't know if there is any way or would make sense even.

You could also do $posting = wire('pages')->find("template=templ1|templ2, album=$album"); To further limit the pages that will be searched. Or if suiteable add has_parent selector $posting = wire('pages')->find("has_parent=id1|id2, template=templ1|templ2, album=$album");

Go to edit your field and under the input tab of the field change the "Input field type" from Select to "Page list select". Tada! You can now browse the page tree On the same tab you can also set the page parent to restrict the list of selectable pages. If you have an awful lot of pages and you're the only one maintaining the site, or other people know what's on the site, you could also change the input field type to Autocomplete (can't remember if you have to install that FieldType module first or if it's in by default nowadays). EDIT: I need to type shorter replies so Soma doesn't beat me to it

You can set the input of Page fieldtype to PageListSelectMultiple to have a page tree to select from. I think doing it the opposite way is much better, have the page select on articles to add albums.

Sounds like a possible RewriteBase problem to me, so I guess that's what onjegolders is referring to with the "~". Site has been developed at the document root on the localhost and then it's migrated to another server where it's run under a user account, for example. So RewriteBase setting would need to be changed to /~someusername/siteroot.

I think that if($page->id) checks here that the page isn't a new/just created one.

@ryan I'd send you a pull request but for some reason my git client doesn't play nice when syncing to GitHub and totally screws up the diff, so no real help there. Instead i'll just attach it here. Basically 'protected function compatibilityCheckPHPInfo()' is gone and i've added that stuff to 'protected function compatibilityCheck()'. This way it doesn't rely on phpinfo() parsing. I've also changed the way the PHP version is checked. I've only done some trial and error testing and all seems well but you and/or other pro's should give it a good look before using it. I hope it can be of some use. - edit - One of those days :S Forum software fucking with indentation. I'll just attach install.php. /me grabs a beer, cheers install.php

closestParent() makes the most sense to me. Though I'm still wondering about just: parent($selector); because the parent() function already implies closest parent (given that it returns the direct parent of the page). So if you provide a selector to it, then it's like saying: "closest parent that has [something]." I also like that extending the existing parent() function in this way wouldn't involve adding a new function to the API. It would also make it consistent with how the child($selector) function works. jQuery uses parent(selector) for something that isn't applicable to ProcessWire. jQuery's parent() can return multiple items, and the selector filters those. So they didn't have a choice to use the parent() function for this purpose. In our context, we don't actually need a separate function like they do.