apeisa

I agree with Family settings. Better to make possible layout options as a separate selections and not tied to templates.

That would be great solution! Two flies with one stroke! (not sure if you use that phrase in english?)

Currently after each save PW admin shows lines for each changed line. While I like the idea (it gives nice comfort that each change was successful) there are few problems: -It shows field name instead of field label. I usually have field names in English, but labels in multilang. So for Finnish users it will show something along these lines: Muutettu: summary. That is problematic, since word "summary" is nowhere to been seen. So simply using label instead of name would help here. -It shows own line for each. On first save and certain pages it results 10+ lines above the form. More aesthetics than anything else, so not critical.

Found one bug from latest version. If you only allow certain template as a child (like a blog-post under blog), then publishing those pages fails to this error msg: Missing required value (template) Reason for this is simple, this is how the template dropdown is on code: <select id="template" class="required" name="template" disabled="disabled"> <option selected="selected" value="48">blog-item</option> </select> Since it is disabled, then it wont be posted at all. I think there is two possible fixes: either make template selection not required or then just remove the disabled="disabled" attribute and use plain text and hidden field instead. Not sure if readonly (which is similar to disabled, but still sends the data) works with selects.

Nico:I haven't tested this yet, but guests should see public data through se.

Datefield bug might be unrelated to this module. Pw improved datefields recently and some fields need re saving.

There is a bug (probably mine ) in current code. From line 157: https://github.com/f...ges.module#L157 // Publish pages with a publish_until date > current date if($p->publish_until > $time) { $p->removeStatus(Page::statusUnpublished); $p->save(); } If you have unpublished page where you have set publish_from field, but left publish_until empty, then it won't get published. I think this is the most common scenario, so strange that this hasn't popped earlier. Easy fix though: // Publish pages with a publish_until date > current date (and publish_until is set) if ($p->publish_until > 0 && $p->publish_until <= $time) { // We keep it unpublished, since publish until is set and valid } else { $p->removeStatus(Page::statusUnpublished); $p->save(); } I know that could be achieved with simple if instead of if else, but I think the logic is simpler to understand that way.

IE9 is actually pretty good browser for browsing. For development not so good. Really looking forward for IE10 release.

Hidden pages are excluded from all queries that return multiple pages. Things like find(), children() etc.. But since get() returns only single page it is assumed that you really want what you are looking for. So hidden pages are returned in get(), but not in finds (unless you explicitly say include=hidden).

You heretics!

Didn't know that include=all works with get also (since get doesn't check for access nor hidden). Soma, have you ever had need for it or checked for this? Feels just plain wrong to use it like that

That is a really nice looking site there! Congrats for the first pw-site, that is probably greatest "debut" I have seen. Can't wait what you will build next

If you want it show up in get() / find() operations then you want it to be published. Unpublished is not suitable then - it means something that is not ready yet, work in progress, draft... PW 2.0 didn't even have unpublished status, so you can go without easily and it's more for content adding phase for editors than for site building. I think what you want is just hidden for the parent page, something like this: /category/ (hidden) /topic/ /another_topic/

Hmm.. I don't actually know whether get should "get" the unpublished page or not. I guess not, since that is not published - so it doesn't exist. I have never had that kind of need myself. Why you need it unpublished? If it is purely "metadata" then just keep it hidden and don't create template file - then it throws 404 if accessed directly.

You need to edit the home template, access tab and "activate" the new role for your home template (it will inherit from there to other pages too).

// Did you know there is [php] tag also function testIndention() { // testing $intendation = 123; } // test result: indention doesn't work in [php] tag either

Pete: for me this is much better than the last one. All my gripes are with the rteditor. It would be great to have textile or markdown with live preview + attachments.

When using multisite module "closest" would also be very handy. There the rootParent is actually the "root" etc. Of course parents("selector-here") would work too. Also I have several cases where I count for how many parents page has and based on that return ->eq(1) or ->eq(2). I think in many cases closest would have been helpful.

I love the mobile theme, it's great. I dislike the CODE tag. I hate when I copy paste I need to always use the "Paste as plain text", since otherwise it just messes up.

Not yet, but I have strange feeling that we might have one sooner rather than later. Here are the latest news from that front: http://processwire.com/talk/topic/1237-history-module/#entry11098

Excellent idea!

Agreed. I thought that I build this module in 30 minutes, but it took over 2 hours of tired debugging... I haven't looked this with fresh eyes yet, so there might be something totally strange.

I hope to get some time to finish that data import module. Although I feel like dropping XML support and make it work well with JSON first. JSON is so much simpler data model without all those attributes and other nasty surprises that XML is full of.

Also it's fine to have some blanks. Some of the translations are for site builders only (not visible for clients) and I like to keep that part of pw in english.

Nope. This logs you in (or creates a new user) to processwire using Facebook credentials. Similar functionality can be found from these forums for example. What permissions you give your "Facebook users" is up to you.