alan

Thanks Soma! Going with: as I love that DRY approach and clarity and also because I still am not at a level where this: is self explanatory for my. I wish it was, but "have a hook" is not something I understand (even though I have used it with instruction to work with Forms for example). If there's a tutorial that would let me understand your second solution then I would be very grateful to know And thanks again for the great pair of solutions! Cheers!

I am allowing some users limited access to the Admin with Users/Roles/Permissions and adjusting Templates to allow them to create, for example, child pages beneath the top level pages on a site, and want to ensure they can only create one depth so they find they can do this: Bios > ChildLevel1 bio1 Bios > ChildLevel1 bio2 but can't do this Bios > ChildLevel1 bio1 > ChildLevel2 bioN One way I can see I can achieve this Assuming the template for Bios is called normal-page I can see that I can solve this by creating a template for the ChildLevel1 e.g. called normal-page-child, a duplicate of normal-page, and set it to use the same template file and set it so it can't create children. Problem solved. But if later on I make a change to normal-page (adding a new field for example) then I need to remember to do the same for normal-page-child. Not onerous but if I had 20 different templates it would be easy to forget that sort of thing. Is there a neater way to limit child depth? Thanks in advance for any comments!

For what it's worth, MM 2.1.2 and PW 2.4 on MAMP running PHP 5.4.10 on OS X 10.7 and all AOK here.

Given the cool new stuff in config.php such as new image options, I would have been happy to have been told by the upgrade process to replace my config file with the new one (copying over my own items such as DB settings etc). I'm sure this was considered and on balance was seen as sufficiently unimportant to warrant adding a step to the upgrade but perhaps a note along the lines "If you are keen to have the latest settings that offer additional control then optionally you may choose to replace your config.php file, taking care to not lose settings specific to your install such as database parameters.". would be a useful compromise? Edit: I just went ahead and did this myself and the only problem I ran into was the site reporting: Warning: strtotime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /Users/alan/.../example.ca/live/wire/core/Page.php on line 398 So I added in from the old config.php /** * Timezone: current timezone using PHP timeline options * * To change, see timezone list at: http://php.net/manual/en/timezones.php * */ $config->timezone = 'America/New_York'; and the error went away.

I am pretty sure on 2.3 I was seeing an error when editing the Home page, I have moved to 2.4 and now the only place I have seen this error is when editing the Admin page: Not a problem for me at all, I just hope it was helpful to report it here and I am not missing something silly.

Thanks for the tut everfreecreative, very good write-up and super-helpful

U r a star kongondo, I had not noticed I needed to go to the user Profile to select it! Thanks!

Love the new Admin theme. Trying to work out how to change colours and having read this and other posts in this thread I am now at a point where I have created Soma's Teflon into a Module and added it and see it listed, but, the new PW 2.4 stock theme is still what is showing. Do I need to uninstall the PW 2.4 theme to get site/modules/ Module themes to work maybe?

+1 diogo—welcome Alex And me too re the logo, saw it over on bitnami and love it. Whoever is responsible, thank you for the great result!

FAB! Thanks for the experience and advice cstevensjr

Thanks Soma, I understand completely, it's a 'nice' Module that is not invasive and as you note should it break for some reason I would be able to work-around that with normal PW code and small changes. Thanks for your fast and helpful comment

Ah ha! Thanks @kongondo V. nice feature.

In Upgrading from ProcessWire 2.2 or 2.3 where it says Does that mean that for mynewsite.com if I am developing it locally at domain mynewsite.com.site I would have in config.php (and config-dev.php) I would have? $config->httpHosts = array('mynewsite.com', 'www.mynewsite.com', 'mynewsite.com.site'); i.e. every domain that I expect the site to run from? If the answer is "yes", cool, and out of interest what does this do, help with potential crossdomain errors?

Thank you Ryan and friends, excited to go and try 2.4 (I am so behind the curve with my 2.3 sites Cheers!

Hi Soma, THANKS for this module! Is this still true?: I have a site about to go into production (I'm about to upgrade it from 2.3 to 2.4 too before it goes live). Would you recommend I not use ImagesManager due to it's Alpha status? I know if I use it it is at my own risk no matter if you say yes or no

Welcome; one other place to check is approx. same place but "Send an email to administrator(s)".

@lenoir, I had a problem with emails going to spam. For me the issue was I think the number of HTML links in the email (it looked as if perhaps the more there were the more algorithms saw an email as spam). So I reduced the number of links as much as I could. Setting the email sender address is something I asked about too. I just checked and I believe set it by going to Form > Actions > Tick Send an auto-response email to submitter > open dropped-down detail row for Send an auto-response email to submitter. Good luck!

Wow. Wow. Wow. I am SO totally grateful to you Ryan (and helpers) who have made it possible to customize and use CKEditor inline mode (or regular mode) with custom style of how content typed into a textarea looks (to me in the Admin as I edit) and also begin to develop and apply custom styles that also allow me to change how content looks on the site to visitors by allowing the editor to apply custom styles. Sorry, I am making this sound more complex than it is. I just stumbled on those two write-ups you did from the links in the Field > Input (the two links noted in your post). This REALLY value-adds the editor side of PW for me, allows me to allow clients to add custom styles to contents and is a GREAT benefit. Thanks!

*LOVE* Modules Manager Notification. Thank you Soma

Love it all. Love the favicon and jealous of it's clarity—congrats!

I don't think it does(?). But you could easily do this yourself. For example create a variable (for consistency declare it in config.php as well as config-dev.php) and test for it. So config.php: $config->showConfigDevPresent = 'no'; and config-dev.php: $config->showConfigDevPresent = 'yes'; Then in your code, for example at the top of every page, check to see if this var is true and if so then have a styled alerting top row (or similar visual cue) to highlight this site is running with config-dev.php present. In fact I think I'll do that from now on! Thanks for asking the question!

+1 re the other suggestions, especially config->debug. Check the bottom of this page where it says The advantage of this is that you can have your local setup verbose about errors and your live site not verbose (by setting the config->debug differently in the two files). If you are very new then you may want to come back to look at this later since it's just a nicety (but a very nicety I think ) Another good thing that is sometimes appropriate is to build and test the HTML+CSS+jQ first (ignoring any PW) then gradually introduce PW so for example have PW replace a static TITLE tag with data generated from PW.

@Chris Rosenau I also had a similar question to yours though I got there via a different route. Although what I've said below has already been answered by @Martijn I'll answer in the way that I 'got' this in case it also helps. I had been cheerfully using code such as: $input->whitelist('sort', $sort); (and $input is of course detailed in the API). But my uses had been in 'in-line' PHP code (not in functions). Then later I started to write functions and all of a sudden stuff stopped working, which is when I had what Martijn notes above explained to me, that the scope matters. In other words to do as I did above but in a function I needed to replace the 'special' / ProcessWire $input with wire('input') so the following is the same but will work in a function (or in in-line PHP code): wire('input')->whitelist('sort', $sort); Now when writing a function I automatically just see myself writing $something and replace it with wire('something'). And many just write the wire('abc') way all the time, whether in a function or not as it makes the code transportable (work whether it's used in a function or not).

This and this are two things I have missed in the past. This is one of the best things about PW, that new knowledge like this is so applicable and powerful because while some of it directly solves a question also so often I am able to take away general learning and do more with it than the sum of the parts. So much better than just learning what a new proprietary tag in some other CMS does. Thank you very much Ryan.

I *will* be!