kongondo

I'm answering this quickly without thinking this through properly..... Changing themes could mean either different HTML or different CSS or both....Whichever way, you can do it either manually (admin makes change) or automatically. Automated: Seasons start and end on specific months/dates. PHP can tell what time/date/month/year it is. Hence, the process can be automated. If it is just CSS, you can have a conditional in your template file that checks the date and includes the right CSS for that season, e.g. if month is June, include this CSS, else....blah blah. Or use a switch statement + offer a default. This is quite easy to do. But, someone will have to at least visit the website for the change to be effected (or you can automate with a cron job) Manually: There are a couple of ways of doing this manually. 1. Set up a single page reference field which will only allow selection of child pages from one parent page called, e.g. "seasons". "season" child pages would be, the seasons - "summer", "winter", "autumn", "spring" - or however many seasons you have . Select a season and save. In your template file, you could do several things, e.g. have a conditional or an include like this .....include....path/to/your/{$seasonpagefield} . css....as an example, where $seasonpagefield returns the name of the selected season child page (which matches the name of your CSS file). Or, if changing the markup too, you could include "summer.inc" or "spring.inc"...etc...you get the idea. 2. Use radio fields instead...The rest is the same..... If doing it manually, you could even even set up a script to send admin an email to remind them to change the theme when the season changes... Just some quick ideas but this should be very easy to do, I think....

Thanks for sharing Marcus. Looking good!

Let's just say "localhost" has bitten him once or twice before.... . It's somewhere here in the forums...

No worries.....oh, you've given me a new name too @Teppo: I know what you are thinking......

In your site config.php... Remove localhost from the array here $config->httpHosts But add yours like so... $config->httpHosts = array('domain.com', 'www.domain.com'); //Replace domain.com with the hostname(s) your site runs from. This is a new recommended security feature in PW2.4

This sums it up for me...'nuff said!

I'm not sure which bit ticked me off more: 1. Really...seriously? 2. All of PW is classes [OOP]. What does this mean -> 3. Please... And why would we want this?

He obviously doesn't know what he's talking about....I did all I could to restrain myself from responding....

https://processwire.com/talk/topic/3067-basic-website-tutorial/?p=58269

Ah, now I see. Sorry, I didn't read your OP clearly and visit that website.

@Diogo, That's what caribou said in his edit (top of the OP)....he changed to double quotes

What do you mean exactly by a webapp? As for CRUD, are you talking about this in the frontend then? Are you talking about a members only type of site, where you have to log in to edit your own page. Are you talking a social network site?....CRUD is possible but difficult to give you a more concrete answer unless we know the use case.

http://processwire.com/blogtest/tags/ http://mods.pw/2M

What other CMS would that be? Just curious...or maybe you've already mentioned this and I missed it ...

IDs are handled uniquely (as in Primary index) and incrementally (like in all other CMS)....once it's taken, poof! it's gone... ...don't worry too much about pretty IDs....the DB doesn't care

Something like this could probably work.... $x = $pages->get(1412);//necessarily verbose - could have done this in foreach foreach ($x->myPageField as $f) { if ($f->name == 'example') {//set your condition $x->of(false); $x->myPageField->remove($f); $x->save(); } }

Would that be the 100 tabs you have open at any one time...?

That's what I said...that tutorial is not really what you want...it was a btw...Dynamic population of dropdown lists is another matter altogether which I haven't the faintest clue about (i.e. in the Admin) save for that it will require some Ajax.... Sorry, I can't be of help...

Yes..

Have a read here.... https://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/ It is not really what you want, but may answer questions about relating pages...

Me?

I have tested with 2.2.4 and the "no parent" behaviour is similar to the present; not visible at create ("add") but visible and permissible at "edit" within the "settings" tab...[i.e., ignores "no parent" setting] I still don't get the logic...We'll have to wait for Ryan to chime in

I agree. Like I said, for the "no children" allowed setting, it works just fine; no children can be created using "new" in tree and the children tab is hidden when editing pages using that template. Likewise, logically, I would have thought that the template setting ..."no new pages" aka "parents" would be respected throughout...Unless there is some other thinking Ryan had? But, look at his is comment in the code in the Class Template: I'm going to test with older versions of PW to see what the behaviour was then...or have you tested?

1. Create a page: sitemap will not be available in the templates drop down - which is expected due to Template Family restriction (no new pages) 2. Edit the new page: sitemap is available under "settings". OK, so I thought I'd get an error if I tried to change the template to sitemap but nada! I am able to do it I have also tested with search template... The only Family restriction working fine is "no children"