Improve admin/content view

The default view has been added, we can customize it now!

I guess we really need some css for the exposed form?

Yeah, we probably needed it anyway, but this just really really shows that we need some.

AT least in d7 there has be some for that ... was that defractored?

But i guess adding special css should be done in a follow up. Let's make this patch more simple and don't chance items per page etc.

In #2020167: Add a name and email search field to the admin/people view (that was previously titled "Improve admin/people view") we decided to:

1. not add a "items per page" filter (we left it for #2020449: Provide a generic/reusable widget for configuring the number of displayed items per page in admin views listings.)
2. add a unified name/e-mail search field
3. change the status filter from 'yes'/'no' to 'active'/'blocked' (actually a follow-up: #2024893: Change status filter on admin/people to 'active'/'blocked')

For consistency sake, we should:

1. leave the "items per page" filter to #2020449: Provide a generic/reusable widget for configuring the number of displayed items per page in admin views listings.
2. add a unified title/body search field
3. was done in #2022127: Change status filter on admin/content to 'published'/'unpublished'

I specifically would like to see #2 implemented (we only search title currently).

Here's a unified search field.

Just gave it a quick spin at simplytest.me and it works. Thanx!

Does anybody else think that we should throw an "Author" autocomplete field and perhaps a date/date-range one too? I mean, since date.module is in core now and all.

Also, should we list the filter widgets according to the order of their respective columns in the results table? Does that make sense?

Until someone works on #1838242: Provide Views integration for datetime field, the Views/Datetime integration is all but useless.
Author would be a good idea.
I don't care about the order.

We also need to expand the existing test coverage for this.

This adds potentially performance problems as it requires to search in a textfield.

I care more about the body field.

Marking as 'needs work' since tests are still necessary

text edits

...moving #2022127: Change status filter on admin/content to 'published'/'unpublished' from the related issues to the children/follow-up issues (could not do it directly from here because of #2130889: Allow adding child/follow-up issues directly from the parent issue and converting related issues to children.).

9: node-2001922-9.patch queued for re-testing.

(Merging "node system" and "node.module" components for 8.x; disregard.)

We need an issue summary which also describes what this actually is about.

.

Sorry for the noise. Looks like the component is stored as a string value so we'll need to update these nodes programmatically before we rename the component.

I believe #1279652: Add title search feature on the node listing admin page going in renders this issue moot. Sorry, I didn't see it. :( In defense, that one is a bit older.

...not entirely moot. See updated issue summary.

@irinaz: please see my reply in #1279652-37: Add title search feature on the node listing admin page. The feature to search by title was added. What we are asking to be done here is to rearrange the fields in the form so that the title search field comes first and that all widgets and buttons are horizontally aligned instead of stacked vertically.

Here is an attempt at aligning these. I've moved the title to be the first field and changed the css for the views.exposed_form to float the action buttons to the end of the fields.

Meant to mark this as needs review.

Works as expected. Updated the issue summary with before/after screenshot.

We can improve the alignment of the button and the form items but using the ‘small’ button type.

I've also tweaked the rtl styling and wrapped the whole thing in a media query as things start to look pretty messy around 490px. Arguably we could set this higher as we start to get orphans around 750px;

...yeah, sorry I tent to forget that we are responsive and only test on wide desktop screens. I'll try to remember to also test on mobile.

36: admin_content_view-2001922-35.patch queued for re-testing.

When selecting a filter a reset button appears, that button is bigger than the filter one :). Not good.

Ah good point.

1. Patch no longer applies

2. +++ b/core/modules/views/css/views.exposed_form.css
   @@ -2,19 +2,25 @@
   +  .views-exposed-form .form-item {
   ...
   +  [dir="rtl"] .views-exposed-form .form-item {
   ...
   +  .views-exposed-form .form-actions {
   ...
   +  [dir="rtl"] .views-exposed-form .form-actions {
   

   The .views-exposed-form class has been abstracted into .form--inline in #2333719: Abstract Views Exposed Form styling out into a reusable class

Hey.. this patch not longer applies to the current 8.0.x HEAD...

I'm uploading this patch that tries to do the mentioned thing.. but

filenames doesn't exists now so I found the moved files and applied the changes there.
css classes not exists now. So the button stays on a new line like in the before screenshot.

I don't think that making all the actions of the views exposed forms should have that css.. and stay the way it is, because maybe other modules add actions to this view and all the buttons in the same row as the exposed filters could not be nice...

So, please review and if not then return it back to needs review

Cheers!

I updated the styling of form--inline.

Placing the title to the front works a lot better, thanks!

I'm not so sure about the small submit button however. Especially when the view has bulk operations, the submit button feels a bit too small compared to the bulk operation action. Let's at the least have a usability check before we implement this.

Either way, the form--actions margin should not apply for small viewports as it pushed the form action too far away from the form elements:

Attached screenshot for the reference, review the patch.

Applied patch #58 .Now the filters are in same level
Attaching screenshots

Mobile view:

RTBC

Unable to apply patch in drupal-9.3.x-dev Showing error
Needs to Re-roll

Not really sure what's trying to be accomplished here? If it's moving the filter button to be inline I think that should be reflected in the title. And this ticket should be moved to whatever theme it needs to be but this does not occur in the claro theme which is to be the new default.

Moving to PNMI for summary update.