tpr

I think it's fine now, just committed a fix to github. The Reno theme has the 'modal' class on the html while the default theme has on the 'body' and I was unaware of this until now. Now I fixed this issue only but maybe there will be other places where it needs to be checked.

You mean the line on the top (sorry, your bug reports are often hard to understate, a picture itself doesn't say too much). It's the breadcrumb, just noticed that the 'modal' class is added to the 'body' in the default theme. Will fix soon. Any update on the ajax-loaded field issue? Is there any js error in the console?

Just committed a design update for the Submodules sections, see the updated screens in the previous post.

v059 is available with the features and fixes mentioned above. The 'Submodules' section in the admin has also got a minor redesign.

Seems like you're using AOS. Great Here is a preview of truncating long titles:

For the long headlines I may add a truncate option, with the entire text visible on hover (simple title). This is not nice but it's better than having the whole title invisible when it's pushed downwards. The problem is that the fixed header has fixed height, and some other fixed elements are dependent on this height, eg. notices, tabs, etc. So truncate would be the easiest/safest way of solving this I guess.

Yes, works fine on 2.9.2.

Well, not sure what's going on. Now it works fine, though I updated to 2.92 and then reverted to 2.87. Works fine here anyways I got 'Error in DumpsRecorderPanel...' text in the panel itself. Maybe what I was about to dump was so dumb that it would need a DumbsRecorder instead

How to reproduce this? I wasn't able to when setting a CKEditor field to be ajax-loaded. Plus have you tried it without AOS? If this happens to AOS enabled only, could you narrow it down to any submodule? I have a few updates under the hood in my dev version but I don't think any of them would have fixed this.

It seems that the Dumps Recorder doesn't support adding titles to dumps, eg. this one results in error in panel: bd('hell world', 'title');

Thanks, I'll see if this whether it break anything. Here is the final UI for the roles. The asm selector went to the upper right corner of the submodule, having it below the label as before occupied too much space (almost doubled the upper fieldset height). It's not entirely consistent in FF-Chrome-IE but differences are mainly cosmetic so I don't tweak it more. Unfortunately the AOS page loads a bit slower because JS needs to change parent of 20+ asmFields which I'm afraid I can't optimize, but it's not that bad. Restriction are not applied so far but I hope it's only a matter of removing submodules from the enabledSubmodules array. But I feel that there will be exceptions here and there, as always

Thanks! When the number of the settings go high it's better to apply some UI tweaks to make it more readable. Most of them are CSS only, others have a bit of Js but they would be usable without Js too. I'll remove the greyed out check boxes, lets see how it goes.

Ok, I think I got it, with a little help of JavaScript. Now I just need to allocate some time to add this to all submodules and beat this through the whole module

That makes sense, thanks. Anyways, adding a general role based permission to each submodule in AOS would solve this too. The implementation seems not that hard but first I need to figure out the UI for this.

I haven't got the need for this so I need to think about it a bit more. Are your "editors" responsible for only one language? On "think more" I actually meant that it would be better to create a module setting that is more general. For example a setting where you could enable/disable submodules for each role, eg. using asmSelects. It's just a quick idea but this would allow fine-tuning permissions for every submodule.

Thanks Z-I-M! Fixed. v058 is available, containing the AdminLangSwitcher demoed earlier. I may add a setting to "Switch language title and name" to it later.

This is very similar to what I used when creating a sidebar archive recently: It's ajax-loaded (plain JavaScript), and results are cached. Btw, watch out when using cache on a multilanguage site because if you don't name the cache key differently for each language you'll get incorrect results. I use the language name as suffix, eg. 'archives' . $user->language->name in this case.

No I'm not But in the movies "Z-Index-Man vs TprOnSteroids" would be a blockbuster for sure

AdminLangSwitcher is coming! This makes easier to see the admin in the selected language. Useful to check the page names and other stuff in other languages. Implementation is quite easy, it just sets a cookie with JavaScript and then sets $user->language based on that.

Perhaps you should install a site profile and see how it's built, e.g the Blue VR or Zurb profile: http://modules.processwire.com/categories/site-profile/

I was on the right track when I posted the snippet above. I suspected that $user->admin_theme is not available until there's only the default theme and apparently that was the case. That's another question why my condition was always FALSE above but it's hard to bugtrack blindly Try v057, it should detect the current admin theme correctly. If there isn't any then $config->defaultAdminTheme is used. Btw, it was the first time I used grabpw.php to install PW (by Soma) which made things a lot easier. It downloads the 2.7.2 version so it's recommended to modify the "SOURCE_URL" to the latest PW version (otherwise you can use the module ProcessWireUpgrade to upgrade from the admin). TracyDebugger's Console panel was also of great help identifying the issue. Otoh I'm not very satisfied with the current html classes solution and regexp implementation. I may rewrite this very part in the future using data- attributes.

Yep, it should, but as @szabesz reported the Reno theme has issues. Anyway, I'll look into it, until stick with the non-sticky header

Thanks. The problem is with the default admin theme. I decided to make things simpler and add its class to the html instead to the body, but it seems some PW installations doesn't return the $user->admin_theme like on in my sites. I hope I can figure out why because there are some tweaks where I use need to check which theme is active.

Ok, thanks. I'll try to rewrite the CSS to use body classes instead html. But first I'll make a clean PW install and see if I can duplicate the issue.

Still no idea why you guys don't have this class. Anyway, could you try replacing line #323 with this?: $this->adminTheme = (isset($this->user->admin_theme) && $this->user->admin_theme !== "") ? $this->user->admin_theme : 'AdminThemeDefault';