apeisa

I just checked what the missing feature is, and it seems that we require filereader API: http://caniuse.com/#feat=filereader (not supported in Safari 5.0, 5.1 and support unknown for 6.0). BTW: IE 10 will have it, and even Opera mobile and Android browser can handle it... I also noticed that we don't actually check for drag and drop support. This fails in Opera 11, since it supports everything else but not drag & drop. It seems that feature check for that one isn't so simple than with other features, so if Opera 11 is only problem, then we might live with that.

Well, if we keep adding options, then JSON is soon much easier than current method Also, if we ever build nicer UI, then JSON is much easier to have at backend than our current method. Also we might think about using YAML, since that is pretty nice to look at and write, but not sure. Seems simpler to go with JSON. PS: Thanks for the pull request. I will test and merge it soon.

I would use internal style sheet, having it's value set dynamically. This would go into your template file (maybe in head, after you have loaded your normal css): <style> #article em { background-color: <?php echo $page->parent->category_color ?>; } </style>

lpa: does this work in your Safari: http://robertnyman.com/html5/fileapi-upload/fileapi-upload.html

Great stuff Pawel, thanks for working on this. Feel free to send pull request. I think this is improvement that everyone wants! PS: This is module is becoming pretty nice community effort: three different developers + one sponsoring. And also using one third party open source tool, jCrop.

One quick solution: set the other templates than checkout to allow only http (edit template -> urls -> Schema/Protocol). There are many other ways (like custom redirecting, or manipulating/prepending the urls on checkout page).

I agree with Diogo here: no reason to be too specific how these should be written or produced.

Does that mystery page have same template than all the others? I don't think you can have page without ID, probably just different template (with no organization-field maybe?) or something like that.

Textile and TinyMCE are pretty different beasts, there is actually very little on what to compare on feature wise.

Wow - pretty amazing case study, well written and very interesting!

I agree that template level settings would be a nice improvement. Unfortunately I don't have any time in short term with this module (other than possible bug fixes).

I am really loving this feature, great stuff Ryan! One very minor thing I noticed: if you have added template context settings for title field, it doesn't use those on /page/add/?parent_id=12008 page (first view when adding new pages).

I think you have misunderstood the resulting UI here. For your end user, it will be exactly same experience. Easy drop down selection for section, and each article is directly under the magazine page.

I think that for this kind of features you don't want to use this module, but native pw-implementation using Page-field. Create hidden page called "sections", under that page you have three pages: feature, health and lighter side. After that you create page-field which allows pages under that "sections" page. This way you get real relations between sections and articles, you can easily scale (remove and add sections), it even works when you later decide that one article can be in multiple sections etc... Also it allows easily to change inputfield, so you can have dropdown, radio buttons, pagelist, asmSelect, checkboxes, autocomplete... whatever is required.

Just pushed changes made by Ryan. They went in almost exactly like that.

http://net.tutsplus.com/tutorials/php/php-5-4-is-here-what-you-must-know/ Anyone tried running PW on php 5.4 yet?

Ryan, thanks for suggestion. For some reason I thought that $_GET['it'] has only path values like /fdas/asd/ (like htaccess wouldn't send it to pw otherwise) but of course that isn't the case (we can have get parameters in url). I will update my code soon. Oliver: you could definitely use this for m.domain.com type of stuff, actually a great use case for this module also. Many of our clients tend to have multiple smaller sites, that need to use data from main site, are maintained by same people, but usually have different marketing domain and own visuals. That is the original need for this module, but actually I would probably use this for m.domain.com type of mobile versions also.

This came up once again when I was teaching PW for our clients. It was 5 min for the first "Oops, I deleted something and I want it back". What I started thinking that how about having this with additional page status, something like "removed", which hides it all together from admin site tree and makes it unaccessible from selectors. But it still keeps it original position and it isn't moved anywhere. It could also have some "safe time", like 30 days before it is removed finally (or maybe moved to the current trash). Then we would have "personalized trash", which would show all the removed pages that user did have editing access and they could edit and recover those pages. Just an idea - I do find current trash somehow limited.

(Added by Soma) Note that this module is deprecated. The newer and more maintained version is found here: https://github.com/somatonic/Multisite/ You can get the current dev version here https://github.com/somatonic/Multisite/tree/dev (Original Post) Just pushed simple multisite module to github: https://github.com/a...ultisite.module What this module does? It allows you to run multiple sites with different domains run from single install, using same database. While you can easily do "subsites" like www.domain.com/campaign/, this allows you to turn that into www.campaign.com. This is nice stuff, when you have multiple simple sites, that all belong to same organisation and same people maintain. How to use it? Just create page with name like www.campaigndomain.com under your homepage, then edit this module through modules menu and add same domain there. If your domain resolves to same place where your main domain, it should just work. Please notice that if you have editing rights, it allows you to browse the site from www.olddomain.com/www.campaigndomain.com/, but users with no editing rights are redirected to www.campaigndomain.com (this is because session cookie is otherwise lost). Any problems? Not any real problems, at least yet known. Of course think twice when deciding should the site have own install instead of this. There are few benefits, like getting data from other sites, one admin view for all sites etc... but it can easily get out of the hands: number of templates, fields etc.. It is harder to maintain for sure. Isn't there multisite support in core? Yes, kind of. It is very different from this. It allows you to run multiple pw-installations with shared core files (/wire/ folder). This is totally different: this is single pw-installation which has multiple sites running from different domains. This is basically just a wrapper with one config field for this little snippet Ryan posted here: http://processwire.c...ndpost__p__5578 (so most of the credit goes to Mr. Cramer here). What it also does is that it manipulates $page->path / url properties to have right subdomain value.

Added multilang support for AdminBar. Also uses template labels if available "New Blog post" instead of just "New" or old db-style "New blog-post".

I don't think so. Advantages are in how to keep code in large sites easily maintainable.

Tested this and it works flawlessly. I updated the module code few replies earlier and will push this to the github soon.

Brilliant news Ryan. I went to see earlier if path() or url() is hookable and realized that they probably aren't because of these reasons. I will test this very soon!

This is also interesting: http://foundation.zurb.com/

Nice stuff Ryan! I updated, but cannot get template field context working? Should they work by just clicking field title from template view? It was an cache issue. CTRL + R few times did the trick.