SiNNuT

I don't have problems with it? Have you by any chance accidentally clicked some of the Other options? This gotcha hit me in the past (as well) Other Just items I follow Items I participated in Items I started

It would be an interesting statistic to see how many times the 'problem' about single/multiple image and file fields has come up on the forum

It's not an issue, it's just how PHP handles things, and is not specific to PW. Variables will not get evaluated inside single quoted strings. edit: for future reference: http://php.net/manual/en/language.types.string.php

Wow, nice case-study! The site performs well, visiting from The Netherlands. Did you develop a custom module for "Scheduler, for advanced date publishing"?

It's kinda hard without knowing how that site exactly works, but i think almost any site can benefit from ProCache. You can enable cache on pages (templates) where it makes sense and leave out the ones where it does not make sense. Also, you can define what happens on page saves etc. http://processwire.com/api/modules/procache/ I think it will enhance the performance of almost any site, in varying degrees.

nice

Yes, i think so. Especially if adrian is right and PW silently goes replacing symbols with dashes (won't be able to test myself the coming days).

This is a nice discussion about page versions/drafts, and workflow. It's interesting to see how different people assess the usefulness and potential use for this kind of stuff. In my mind page versions and a basic workflow like concrete5 has in its core, could be valuable additions to PW core, or maybe as paid modules. The way i could see page versioning working on a page live-cycle: Create a page 'Save+keep unpublished' would create version 1 with status 'Draft', whereas, 'Save+publish' would create version 1 with status 'Published' Editing the page, will… …create a new (Draft) Version, maybe with options like 'Save as draft', 'Save draft' and 'Publish (this draft)' Publishing a draft, will… …change the status of both the Draft Version (it becomes “Published”)… …and the currently Published Version (it becomes “Previously Published”). ( The above was based on a description of the editorial cycle in a system called EPiServer. ) When you think of it a page versions are nothing more than collections of field revisions? I think page versions (or drafts if you will) would be nice, especially if this is paired with some kind of approval workflow. Of course stuff like repeaters and pagetable might complicate things but i'm sure there are ways to handle this.

Nice catch. This is the first time i read something about session.save_handler being set to anything other than files (this is the PHP default) on this forum. As you noticed this will indeed cause problems and lead to a (for most) quite cryptic error message, and is pretty much a show-stopper. I'm not sure if this happens a lot, but this could be a worthwhile addition to the http://processwire.com/docs/tutorials/troubleshooting-guide/ . Or maybe even better, add a check for this in the install.php/index.php or wherever Ryan thinks this should take place.

Strange, It seems that there might be a stray install.php file at the root dir of production server?? The explanation of the error message comes from wire/core/shutdown.php with the following logic: else if($config && is_file($config->paths->root . "install.php")) $why = "/install.php still exists."; Normally install.php will be removed by the PW installer, but maybe there is something preventing it from doing so. Have to tried adjusting the permissions from within the installer. Or checking if there is an old file 'install.php' that can't be removed for some reason?

Are there scenarios thinkable where a course could have multiple instructors? In that case you would probably want to reference the instructors via a page field belonging to the course template. Or even, when a course can only have 1 instructor this might be best/flexible way. So you would have: instructors >member name1 >member name2 courses >course1 >course2 and then the course pages would have a field of type 'FieldtypePage', where you can choose one or more instructor pages, depending on your needs.

I do agree with Soma that over time there have been quite a few users that expressed their (big) interest in PW (page) versioning capabilities. On the other hand it's also quite hard to estimate how many PW clients would actually go on to use it. But a killer feature nonetheless, if done right. Anyway, it's on the roadmap for 2.6+ and if it stays there, i personally think it might be a good thing if the versioning, enhanced workflow and js session monitoring became a priority after 2.5. Why? Because i think these 3 items kinda go together. In my mind a versioning system really has the most use in some kind of editorial cycle where multiple people can work on a document (page) and maybe put versions up for review and approval, or other workflows. Ideally this would be be accompanied by a way to compare differences between the published version and/or draft versions. Maybe some inspiration can be taken from the VersionControl module by teppo. But maybe i'm taking this too far. I would be curious how Ryan sees the scope of versioning capabilities and related subjects.

The small project walkthrough should get you started http://wiki.processwire.com/index.php/Small_Project_Walkthrough Or the basic website tutorial http://wiki.processwire.com/index.php/Basic_Website_Tutorial

The green looks pretty good on your site. It also depends a lot on font(size) and weight: I pasted the blue below, because i like this color on a couple sites i did. With the forum font and size it is still a tad light. So pasting colors, away from the actual site, doesn't really work (but i still like my blue). I like blue like this #1FA3EC

That's true, on my phone the light blue is also fine, but it's best to play it safe when it comes to these things.

The second one works better for me.

Yeah, on my laptop the links are a bit light on they eye. Could be a tad darker for readability.

It's around 15 mb now? I don't see how that would a drawback, even small. Besides, you can prolly strip out the unneeded profiles if you wanted to. I really like it that there will be a couple of profile in the default package. Should be good for different audiences (learning, experienced etc.)

Agreed, but a lot of that has to do with the fact that some of the popular frameworks (BS, Foundation, UIkit) introduce too much 'design' and UI components, where indeed a lot of the stuff remains unused. There are better options though.

To add to the OT: flexbox (near future) and CSS Grid Layout module (not so near future) will make the task of achieving solid and responsive layouts a whole lot easier. No more floats and/or inline-blocks, finally. (some nice flexbox stuff here). If i where new to RWD and wanted to learn i would probably focus on learning the basics of these new CSS features. For current work i would probably most of the times take a well tested and established grid/framework, because floats and such can be quirky.

What do you mean by 'prevent'? You would want to enforce that children of a hidden page are also hidden? Unpublished pages should be excluded by default; i'm not sure but you've got a funky thing going on. Does explicitly adding status!=unpublished to your selector solve unpublished pages showing in the result?

I don't think that it would make a difference? $pages->find will exclude hidden by default, regardless of permissions and roles

+ a lot, what teppo said RWD is not some kind of afterthought to cater for those pesky smartphones. It's about displaying your content as optimal as possible on all screen sizes and resolutions, from small to large. " Out of interest, anyone else out there want to comment on the responsive aspect Bernhard touched on? - how important do you guys think this is? Most users have tablets or phones which can display 960px sideways, so does a 960px site wide really need to crunch itself down width-ways and be 3 miles deep just to fit a portrait screen? " If i take for example the Springlands Veterinary Centre site : My phone displays 1920 x 1080, so in that sense it fits, but, it's just not a nice user experience. I have to zoom to read the left column, where the main navigation resides. The footer text is so small you hardly notice it. So it's useable, but could very easily be much better. Switching, at some breakpoint, from 2 to 1 column, including a mobile friendly navigation would not be that hard if you design with these kind of things in mind. Imo it brings big rewards. The fixed (960px) layout just doesn't make that much sense anymore. RWD is here to stay.

Would it be an option to call on a external webservice/API? For example http://www.geonames.org has a lot of data (8 million placenames to start with) and a whole range of ways to query their data. http://www.geonames.org/export/ws-overview.html html If you have the countries and 'locations' yourself, it would be easy to use their search service to find places/cities within. Or they also have ways for postal code lookups. After that you can store the found data to PW pages if you wanted to, in exactly the way you want.

Seems like awesome stuff!