Module AdminOnSteroids

[tpr]

It's doable I think, but the question is what is the default user behaviour, save or publish?

You mean very new pages or pages left unpublished for a reason, and then hitting ctrl+s?

[szabesz]

3 minutes ago, tpr said:

pages left unpublished for a reason

This one and not just brand new pages. I think it does not really matter what the previous life of the page was if we went to keep it Unpublished.

5 minutes ago, tpr said:

default user behaviour, save or publish?

I vote for "save only behavior" so that users new to AOS do not trip over it accidentally just like I do  I'm not new to AOS but last time I did not notice that I published the page and it was so for more than a week...  Those who are confident enough could switch to the current behavior but that does not include me anymore.

[tpr]

v162 is uploaded, changelog here. The docs still needs to be updated (FieldOverrides and the new Branding logo feature at least). 

[adrian]

Thanks @tpr and @gmclelland for all the updates. 

Just updated and got this:

[adrian]

FYI, in case it's not obvious, it's a file compiler issue. Something to do with the line breaks. I have come across this once before. It's a pain, but an easy fix.

[tpr]

Thanks, I reformatted that part, hopefully it's OK now (for me it didn't appear).

[adrian]

39 minutes ago, tpr said:

Thanks, I reformatted that part, hopefully it's OK now (for me it didn't appear).

Looks good at my end - thanks.

[gmclelland]

Thanks tpr!

I'm not seeing any PHP errors, but I'm still seeing some display issues.  When viewing the AOS's module settings page with AdminThemeUikit, the enabled modules boxes are to big and the screen scrolls a lot because of it.

To fix it, I had to add to src/aos_config.scss

// fix AdminThemeUiKit from expanding the min-height at runtime
.InputfieldContent.uk-form-controls{
  min-height: auto !important;
}

There are couple of others small issues, but I'll follow up on Github.

[tpr]

In v165 sticky header is available for the Uikit admin theme too along with a compact (smaller, better name anyone?) masthead, plus Profile page links to configure themes (SuperUsers only):

[adrian]

Thanks @tpr - great having the sticky header.

Another one of those File Compiler annoyances that needs a   to fix:

Add links to configure admin theme settings on Profile \ProcessWire\page(SuperUser only)

[tpr]

Thanks, I re-worded that sentence, hopefully that works too (cannot see here the issue).

[adrian]

4 minutes ago, tpr said:

Thanks, I re-worded that sentence, hopefully that works too (cannot see here the issue).

Yep, that fixes it - thanks!

[Juergen]

Only to mention: I know that AOS is not full supporting the new UIKit Theme, but I think I post it nevertheless.

With the new UIKit Theme the description of the fields that are usually shown inside an overlay will be displayed on the left side of the field too.

The hover function works also. This is fe a description of a pagetable field. As you can see the description will be displayed in a small column on the left side.

Best regards

[tpr]

I've just added a feature similar to PrevNextTabs module, creatively named as prevNextLinks  

It's largely based on @Macrura's module but there are some differences too:

• links are added next to the page title which is imo less error-prone
• on the last page the first children is linked and on the first page the last, so there are "Edit prev/next/last/first" links based on the current position
• under the hood links are added to the DOM via JS, which made it much easier to position them and to serve all 3 admin themes (default, Reno, Uikit)
• there is no option to exclude/include templates

@Juergen

Thanks, I'll have a look

[Macrura]

4 hours ago, tpr said:

I've just added a feature similar to PrevNextTabs module, creatively named as prevNextLinks  

this is great!  the only issues i see with the links being next to the title is that they will jump around from page to page, whereas if they stay in 1 place, you can click through the siblings without moving the mouse.

I like the fact that it goes back to the beginning/end also – that's helpful..

[tpr]

That's true but I think it wouldn't be used to quickly cycle through pages.

My first idea was to put these links before the title but that would make the title look odd, though I can change it if there's a need.

[Robin S]

15 minutes ago, tpr said:

My first idea was to put these links before the title

Maybe the arrows could float right next to the Save button? Besides not moving so much between pages, on the default theme it would also have the benefit of less confusion with the breadcrumb separators (which look quite similar).

[tpr]

That would work, but there is an aos tweak to move the save btn next to the title. But perhaps prevnextlinks could be placed to the far right then, will think of it.

[Juergen]

hello @tpr

I have discovered an issue with search box in page table field and updating the page table field via Ajax.

Before:

The search box is there

 

After updating the page table via Ajax (a child page was edited in modal and then saved):

As you can see the search box is gone. After refreshing the page the search box is still there.

I have also troubles with this behavior by using a InputfieldPageTable::render hook (see https://processwire.com/talk/topic/17738-tip-how-to-change-the-table-headers-in-page-tables/). It seems that that the hook doesnt hook in if the field will be updated via Ajax. My attempt was to try to run this hook in init.php but I was not successful.

[Juergen]

Hello @tpr

If you can confirm the behavior written in the previous post, @Robin S helped me out at my similar problem to get it working. Running a slightly modificate code inside init.php instead of ready.php will solve the problem. Maybe its a solution you can also use if you can confirm this behavior. For the solution please click the link to my problem in the previous post.

Best regards

[tpr]

Filter boxes are added via JS so there is no hook there as I remember. Because of this the JS init code needs to be run on ajax change. I rarely use pagetables but I'll reproduce the issue somehow.

[Juergen]

Hello @tpr

You can ignore this "bug". It was caused by a page table hook inside ready.php on my side. After changing my code it works as expected. Maybe there was some interference . Now my code and AOS work as expected - I am happy.

[tpr]

Thanks, I like these kind of bug endings

[Robin S]

Hi @tpr,

I've been having intermittent problems when using the save hotkey. I get the overlay but the form is not submitted. It's been happening on remote sites and on localhost, but I'm not sure exactly what version of AOS I first noticed the issue with. There are no errors in the browser console when the issue occurs. Browser is Chrome on Windows. Tricky one to debug because it only happens intermittently - just thought I'd mention it in case others have been experiencing it too.

I'm wondering if the behaviour of the save hotkey could be a little less restricting so if an issue like this does occur the interface is not locked and the save button is still accessible. Currently I have to use my browser dev tools to remove the height and width from the added pseudo-element and allow pointer events. 

[tpr]

Do you have a field with html5 validation that prevents the Save action to perform? Aos triggers the Save button so this is what I can think of.

I have modified this feature a few weeks ago to trigger Save instead Publish when creating a new page but I don't think this is the culprit. I needed to modify things under the hood to take the DOM order into account, to find the Save btn first on new page.

I guess I can show the save overlay for a second and then remove.