tpr

That was exactly my thoughts when trying the module. However, in my case I need to assign users to page lists and not roles, but I guess it's only a minor tweak from there.

Branch visibility will be implemented only in a later phase, but I used "Page Edit Per User" module plus another one, "Admin Page Hider" (not 100% sure, I tried a few similar, found here on the forums). I just quickly checked if this thing could work and though it wasn't perfect, it looked feasible. I've also set permissions at template level, of course. DynamicRoles seemed the ultimate way to accomplish this but there was always something that didn't work the way I planned. I may put only front-end edit links to editors (using FEEL) to disallow full access to admin. This way I could connect editor to a specific branch (1:1) and simply redirect or show 404 if he tries to access other pages (with a hook). Plus front-end editing can be advertised as an extra addition so chances are this will be the way. I'll come back if this part will be done (and also if not ). However, the project first needs to gain enough interest to be started.

I ended up using 1st level pages for the main shop: (MAIN SHOP) — news — products — about-us — services — AFFILIATES — — AFFILIATE 1 — — — about-us — — — services — — AFFILIATE 2 — — — about-us — — — services This way the urls are fixed (/products, /services, etc). However, these urls are loading the affiliate's matching pages. Subpage are served using url segments. Internal links would contain the full url, inlcuding the main shop's too, which is overriden using a Page::path hook in the ready.php file. The nice thing is that this change seems fully global, so far I haven't found a link where it failed, including the admin pages. So if one affiliate's editor edit its "about-us" page and click on the "View" tab, it will navigate to "/about-us" instead of "/affiliates/affiliate2/about-us/", which is just fine. On template level I have pre-defined variables for the different levels: - $page - $affiliate (the active one that will be determined by domain name later) - $currentPage (determined by the url segment, if any) I'm really happy so far that I'm using PW for this site. There's still a ton of work to be done but it seems it will work. To be honest I don't know how I would do this without PW, but now I can roll out the very first demo in about a week (including front-end development), which is so cool.

At least the design is top notch Why are you looking elsewhere? Looking for challenges?

I think that the possibilities that a ckeditor provides for content editors is just enough, if not too much in some cases.

Thanks, good to know. It were even better to know the cause though I have some updates queued up but no time to look at them in detail

I see. And what if you set all user's default language to the site's default?

Setting guest language plus swapping localization files won't work? Home page name should be also adjusted.

CSS awesomeness! Enter this into the "Text color" field in the module settings: transparent; width: 70px; height: 70px; border: none; background: transparent; border-radius: 100%; overflow: hidden; padding: 0; margin-right: 0.7em; color: #aaa Also set the first field value to "70,70". No matter what you write elsewhere, the code above will overwrite it.

I don't think you can achieve this (maybe 5yrs later ). My first (and only) idea is to use html5 canvas but I'm not sure that would work. Here is something similar: http://cburgmer.github.io/rasterizeHTML.js/

The truth is that both ways sucks from the dev point of view because doubles the development time

Yes, I noticed that you mentioned "current page" so I thought there's no need to use get(). @kongondo Thanks, I always suspected this but never really dived into it

I'm asking for some help/advice here on my next project. There is one main shop and many affiliates (their exact number is unknown but ranges from 50 to about 1000, at max). Each affiliate should have a few own pages (e.g. "about us"), and some that inherit content from the main shop (e.g. "products"). All of them would have their own domain. They wouldn't be so complicated (no multi-language, ecommerce and such). I would like to use only one PW installation with a page structure like this: — MAIN SHOP — — news — — products — AFFILIATES — — AFFILIATE 1 — — — about us — — — services — — — products (inherited) — — — news (inherited) — — AFFILIATE 2 — — — about us — — — services — — — products (inherited) — — — news (inherited) ... The idea is to restrict admin access for affiliates so that they could edit/see only their own branch. I've made some quick checks and it seems to work. We don't expect too much traffic but with that high numbers pages will inevitably go up after a while. I know PW scales well but I just want to make sure. The other systems I know would require much more time and effort, at least it seems so atm. Do you think this setup is feasible or should I look for another solution?

Something like this? if(count($page->children('my_field=0')) == 0) { echo "Sold out"; }

Just to make sure, are those pages active in both (all) languages? (check at Pages -> Settings - > Name, and there's a "Active?" checkbox at the end of the name input field)

Sometimes I use Tracy for debugging (mainly for dumping variables). It's debugger bar sticks to the bottom right corner of the window so it's easy to spot the errors/notices. Of course when using it outside the Nette framework doesn't show queries and routing. If anyone's interested I can share how to set it up in PW (nothing special). I'll also try Soma's logger in the future.

Give them time to find your ticket in one of their random directories

I remember a similar issue with the Reno theme (though maybe wrongly), have you tried with the default theme?

Thanks! Just tried and it works fine. BCE and Migrator saved my *ss today when I needed to migrate 100+ pages, so thanks for these

No idea then. Do you by any chance added a FEEL JS callback? What you could do is add "console.log"-s to the FrontEndEditLightbox.js at various places to see where it chokes. Line 69 is where the style attribute gets removed, try logging before that. If you remove display: none from the element, does it work fine afterwards?

No, that's all you need to do. Do you have "FrontEndEditLightbox.js" added to the site by the module? (check the page source) Using "display: none" is intentional, just to make sure it won't gets visible by the site's CSS. The above mentioned JS should remove the style attribute. The module adds its JS file to the bottom of the page, right before the closing "</body>" tag. The first thing I can think of is that you don't have "</body>", and the second is cache

Is your admin running non-English?

I have bunch of Pages that have I'm in their title. BCE doesn't show them correctly, only the "I' is visible under the "TITLE" column. I can add titles correctly and they gets saved (fortunately). I guess it's a bug. Update: On second save (when title field shows "I" only) the wrong value gets saved.

Thanks for the report! Version 1.1.1 is uploaded with changes below. Yep, my IDE has fooled me. Anyways, I think it would be better to use the unminified CSS, so I made that the default. I'll think about how to implement it. That was one of the latest modifications, somehow it didn't made through. So "text" is the new key for the edit link text ("name" could be confused with the "name" html attribute). Custom CSS styling: yes, you can override in your own CSS file. I'll add a textarea later for such custom styles (only one). It could work if everyone would use only 1 PW page per website page. However, that's not the case so I don't think it's doable (think about 1 page portfolio sites).

That would surely convert many users from other CMSes - so please don't go that cinematic