apeisa

Look at my multisite module, which does exactly that.

Sounds great and you can count me in. I could do a presentation also.

I got it. Probably we can just add them as values for $page object, like this: $page->abEditablePage = $pages->get($product_id); $page->abRedirectPage = $page; // Not sure if this is ever required, we want always return to same url we were before editin?g I'll hope to take a look with this sooner or later. Of course if you (or anyone else) likes to try hacking this you are more than welcome!

I think that could be a good addition. There need's to be someway to tell AdminBar, that "editablePage" is different from "currentPage". Can you tell me more about the context you have this request? Using urlSegments probably?

Yeah, I know it is possible to get drag and drop uploads work in safari - not sure how (since File and Filereader APIs are not supported). After we did build the d&d implementation with Ryan it just felt that "well, Safari will support it soon enough". But it seems Safari doesn't get that much love, since that was about year ago or what when we implemented the drag and drop?

That is how I would do it. In that particular case (male / female choice) it maybe feels overkill, since that is pretty much stable selection (you probably don't have third sex coming etc). Usually this kind of selection can be done with boolean checkbox, but I agree that would not be good in this case. But actually that is not so bad. Usually I have the hidden /tools/ page and under that I would have the "sex" with "male" and "female" children. For this kind of selections I have one generic "reference" template. Creating the pages takes about 1 minute, so it's not that bad overkill If you would like to go the real "overkill" route, then you would create male/female fieldtype/inputfield combo.

I think it would be great to have some basic versioning, even just for textfields would be very beneficial. I know it goes greatly more complicated with files and repeaters, but most (or at least big) benefit comes from just text versions. Page history module is also first item on roadmap, so many people might have high hopes for it: http://processwire.com/about/roadmap/ (if it's not coming for 2.3 then maybe to strike from list and move to 2.4+ part of that list). Also - would it make any sense to have field history instead of page history? Would it be any simpler to implement that way?

Soma, no option to disable / enable animations. If someone doesn't like it, build a monkeyscript or something to disable it. I would say that even the column # option is "little too much", would be nicer to have right amount of columns based on screen width. In other news: I really like the new improvements!

I think those are excluded by default anyways.

Works for me.

It's there already. The datetime field enchantments, not the lang support for it.

Clever module and I love the simplicity of the implementation: https://github.com/r...hHistory.module tsd: it doesn't touch .htaccess at all. If processwire throws 404 it then checks if there has been page in that path. If has, then it checks if that page is still live somewhere and is viewable by current user. If it is, then it does 301 redirect there.

Never got adobe shadow working with android & win7.

I would say it is another cheatsheet or then just another tab/page on the current one. It have to be very clear what stuff is part of the API and what are from modules.

I wouldn't say that language support is a third-party module. I think all modules that come by default are core modules (some of them permanent, some of them installed by default and some of them not installed by default). I think language stuff should be in cheatsheet, but not sure about things like comments, pager etc.. Probably the more the better!

It is always interesting to find where processwire is mentioned, so this is the topic to post links to articles, blog posts, discussions, tweets etc which are about or related to ProcessWire. I started with this one, which is well written article about some basic differences between WP and PW: http://www.globi.ca/articles/articles/processwire_vs_wordpress/

Interesting. I think what we really need regarding documentation are: a) Finish the tutorial (http://processwire.c...ct-walkthrough/) and putting it to the site also, as a first "getting start" section. I am hoping to find time to help Ryan with this one. B) Creating "what's next" section, which has helpful links to other resources and tips how to continue after the first tutorial. It's great to have more resources, but always little worried about disinformation. In the introduction post Clinton writes: There ain't no new user concept coming, that did happen already in version 2.1. The massive number of files and directories PW creates... yes, PW creates a directory per page and that is a problem that is going to be addressed. Not sure what he means with files there and upload / download speed doesn't have anything to do with the fact pw creates a folder per page. Truth is that if anyone wants to contribute, I am sure we find good place for those from the official site also (where most people would find them, most probably). I don't have anything against unofficial docs / blogs / wikis etc, but currently we are so young project, that there is very easy to contribute to the official stuff also. I think we need to better address and communicate this when we get the new site launched. Don't want to sound too picky though - great to see more and more PW resources out there. It tells that we are growing fast! Hopefully the unofficial docs project will keep up the great work they already have!

Very nice site and handy looking plugin too!

How does it fails? Does firebug or chrome console give you any error messages? Also: are you sure you really need repeater inside a repeater? Of course depends on your use case - it very well might be the best possible solution here.

I think it depends a little. The shops what I have been building really were better when different colors were different products. When browsing for products it is much nicer to see different colors right away, on a category level. But of course if you have shop where "the thing" is the design print and you can choose whatever from 14 color for a shirt - then of course color should be a variation instead of own product. Interested in hearing more about this. What stuff was unnecessary for you? Trying to find the sweet spot for the features baked in so that Shop module would be as easy and flexible as possible. Also - excellent that shop module works out of the box with stock variations. I thought it should (since variation is just a page), but haven't got time to test this yet. Is your shop online already Stephen?

And if they don't agree, it is just a new fork or a complete rewrite. I think that "duplicate" modules will inevitably happen and I don't see it as a bad thing only. We wouldn't have a PW, if Ryan would have settled to the idea that world doesn't need another cms. What we do need is that our "modules section" will scale and help to provide good information about each module, so that finding best possible "gallery module" would be a breeze.

Spoetnik, great to hear. I will be adding support for product variations in to the module somewhere between August and December, since I need to implement them for a client. Great to hear that the concept of using repeater for variations works, since that is what I am planning to use in shop core as well! Hard to give much help with so little information. I myself don't like that "variations" are so much variations, that they require different images. I always tell my clients that good example for product variations is different sizes for t-shirt, but bad variation is different colors. Make each color a new product and then each size as a variable.

You cannot create new fields within a template. You only choose which fields you add to the template. And the fields you can choose from are the ones you (or system has) created already. I would say that "best practice" (well, at least I have found it good ) regarding fields and templates is this: -use generic field names whenever they make sense. Good reusable fields are usually named like this: summary, body, image, images, files, featured_image etc... -Don't re-use the field, if it wouldn't make any sense without changing the label. I mean that don't use field called "summary" if it really means "Requirements for the job". Just create a new text field called "requirements" and use that. Yes, this will "pollute" your universal field list, but you do not want to write code like this: <?php echo "<div class='job_requirements'>$page->summary</div>"; // summary keeps the requirements... echo "<div class='how_to_apply'>$page->body</div>"; //body keeps how to apply... echo "<div class='other_information'>$page->headline</div>"; // headline has other information Template field context is a new thing and I want to think the label editing there is just for to give end users a better experience. For things like changing "Title" to "Name of the city" etc.

Few You got almost them all. I think it is some autoload module causing issues. Or then few of them together. It would be helpful if you uninstall those modules one by one and check when it starts working.

No, they shouldn't require any reloading. Which browser and os you are using? Does js console display any errors? What 3rd party modules are installed?