apeisa

Looks very nice and some very great thinking there! About adding new page: what I have been missing would be a quick way to add multiple pages at once. Something like: Click "new" Opens "inline" or modal view for page title, name and possible template Click save, page is added as unpublished to a tree You can click "new" again etc...

Table editor on CKeditor is much better than the one on TinyMCE - other than that I'm not sure how much they differ? Hard to say though before testing more thoroughly. Biggest problems with our clients so far has been: Images, choosing them, setting width/height and positioning them inside text Tables and their attributes

I think other editors (which have been around since IE4) have a lot of burden to carry. Also these new editors are purely for latest browsers and build on html5 contenteditable (instead of textarea). Even the dinosaurs have made that choice: http://aloha-editor.org/blog/2012/08/ektron-editing-content-is-fun-again/

I like it, simple and nice. The main nav is awfully tiny on higher res, hard to hit those links

You might be right. I always try to find all possible ways to keep RTE in minimum, but it is just impossible to avoid situations where client needs a little table there and some images just here etc... But since Aloha Editor dropped the ExtJS dependency and is now implemented in JqueryUI it might be a good candidate. It's also GPLv2 licensed now: http://aloha-editor.org/blog/2012/07/aloha-editor-goes-jquery-and-gplv2/

Yeah, it's been broken since few latest Chrome versions. It's horrible and terrible. Thinking about getting rid of the tinyMCE all together. What parts of the editor need to be tied into PW? Images and links, but is there any others?

Diogo: what about after page id 9999? This is what I did: wire('pages')->get( (int) substr($product->parent->name, 9)) Edit: Soma was faster, again. But we came up with similar solution

Thanks guys. Diogo: This is great, I will get the id from there. Still, if there is cleaner way to do it, let me know! Soma: Only shop I have build don't really use the backend (email confirmation is all they need), so that's the main reason for the lack of focus there so far. Hopefully we get more demanding shop client soon

Using children would require some code tweaks also (to ShoppingCart.module and ShoppingCheckout.module) to append the parent page title before variation title. If variation title is all that is needed, then it would be just the same with repeater. I think this is perfect use case for repeater and much simpler UI than using children pages.

Thanks Soma. I was thinking about the same, tough I think it would be nicer if variation title would be only appended on actual product title. If product title changes, that needs to be accounted etc - more code that way... But if getting the product page through repeater item id is difficult, then I will take that solution also.

Hmm.. this is confusing. $product = $this->pages->get($repeater_page_id); echo $product->parent->id; // Outputs: 92641327 (there ain't so many pages..) echo $product->parent->title; // Outputs: testproduct (this is why I assumed I have right item - "testproduct" is the original page name So how I know the page where my single repeater item actually is, if I only know the id of repeater item?

If I know the repeater page id, is there way to get the actual page where the repeater field is? Some background: I am adding product variations to pw-shop using repeater field. Shopping cart then get's the repeater page id as a product. But since product variation title is something generic like "Size: XL" or "Color: black" I would like to show the actual product title there also. Ok, it seems that parent() actually returns the page I am looking for (I was thinking that it would return the hidden page from the tree). Excellent!

I think it is totally appropriate to have some conventions and not configuration for everything. Trailing slashes are - in my opinion - a good convention.

Same here with chrome, I think it is tinymce that is adding the link.

Well said Matthew, the end result of PW website is really up to you, not what the system comes up with. That being said, I have been thinking a lot about building our own "starting profile" (we kind of have one already, but that is not well build). Something more "out of the box" for our clients. That thinking also has some merits - especially if there are lots of sites and multiple people working (also on different areas, like customer support, developing, sales etc). More feature packed default site is easier to demo and sell, easier to maintain if there is lots of similar sites, easier to provide support (technical and helpdesk), easier to write instructions etc... What I am doing (hopefully this year) is to build site profile where would be the most common needs baked in already. What that would mean in our case (we build websites for Finnish associations) are: News section Events section Contact section Few different "basic-page" layouts Blog (maybe) FAQ-section (maybe) Tiny "intranet" section (maybe) Frontpage highlights Few editor roles Some useful modules already installed (redirects, adminbar, link helpers, admin helpers) Using more robust template approach Responsive by default I hope that it won't take too long that we start to see more and more community driven "starting profiles" like Ryan's Blog profile. There could be things like General CMS profile (kind of what I am doing - although not sure if it will be general enough to share it) and E-commerce site (kind of what here is coming) etc..

http://processwire.com/api/multi-language-support/code-i18n/ Strings like these $this->_("Add to basket") are already translatable through admin. Just install PW language support module and translate all the Shopping module files through it.

Thanks for posting those screenshots guys! Definitely taking some inspiration from there.

Luis: there might be few non-multilang strings on ShoppingOrdersManagement, but other modules should be 100% multilang. Those are fully translatable through PW language translator.

Almost fixed, we are getting there (it's 404 now, missing /modules/ before module name)

Great work Teppo, will test this soon. Based on the login times on the screenshot, this required some late night coding also BTW: Your link to modules directory is for edit view: http://modules.processwire.com/edit/process-login-history

It probably requires RewriteBase to be set. See this line and comment above it: https://github.com/ryancramerdesign/ProcessWire/blob/master/htaccess.txt#L76 So edit your .htaccess and add this line on line 77: RewriteBase /~racc/

Reno: how does your tweaks look when there is repeater with file fields? I think that is scenario where current "boxes with borders" UI really falls apart and is always messy. Look at the attached screenshot:

Jeff posted an issue on github: https://github.com/apeisa/AdminBar/issues/7 I can't reproduce it on Win7/Chrome, so can others confirm the issue with Mac?

If you mean it should be set on body field of demo profile - that isn't necessary since it's using tinymce inputfield which sanitizes it's content based on the editor settings.

Thanks guys for reporting. It has broken so many times, that I think we need to change the way it is implemented. Since this is already discussed in cheatsheet topic (http://processwire.com/talk/topic/681-processwire-cheatsheet/page__st__80), I'll close this one.