🇳🇱Netherlands @johnv

Good to hear that you use this feature!
I cannot recognise the code anymore, since in current dev , a subfield 'status' is introduced.
Please test dev version. I am about to release a new version, so I will wait for yor feedback.

I understand now why sometimes the caching test have the proper results. When executing dpm(), a KillSwitch is triggered by the dvel devel.dumper. That way , the page is NEVER cached, and fresh data is always served.

function dpm(...): mixed {
  Drupal::service('devel.dumper')->message(..);
}

johnv → created an issue.

I tested the patch, hoping it would solve my "Anonymous never get fresh pages" problem for a contrib field module.
Reading the summary closely, it will not, since my use case does not set the Expire, only max-age (there is no guidance how to apply setExpire() by contrib either.)
Anyway, the Summary lacks a test script. I added one. Please correct it if necessary.

Thanks, first step from the 'Remaing tasks' section: revert the type class constants

johnv → created an issue.

johnv → created an issue.

Thanks.

Thanks for your feedback.
What do you suggest me to do?
It seems the change needs to be undone, then generate a new verson 8.x-1.22, then create a new branch 11.x-1.22, and chagne that version.
I seems current version (well, 8.x-1.19) is pretty stable, and changes are pretty much 'techinical debt' due to core / php changes.

The first test: having a 'status subfield in the Views display does NOT trigger an update. The field formatter works fine.

Please check 📌 Eliminate 'status_update', since the Open/Closed status is now Computed, and page cache is no hurdle anymore Active and report back.

Please downloaded dev version or latest active version, apply patch and report back.

johnv → created an issue.

This should be now resolved in dev version or upcoming 1.22 version, with above simple patch, and the fancy 📌 Hook classes are introduced in D11.1 Active

Please try latest dev and report back, since #3494659-14: Error \Drupal::$container is not initialized during Drupal 11.1 upgrade → should have fixed this.

johnv → created an issue.

Re-opening this.
It was suggested by 'catch' that we can just use include_once directly, since we know the directory structure.

// Add theme.api.php hooks.
include_once __DIR__ . '/office_hours.theme.inc';
// Add views.api.php hooks.
include_once __DIR__ . '/office_hours.views.inc';

There are follow-up problems with the current solution.

The views.inc file will be restored.

Thank you.
ITMT I coincidentally did a check on code styling, and all occurrences were reported by phpstan, and fixed in #3219111-114: Clean code → .
You will find the result in current dev version or upcoming version 1.22

johnv → created an issue.

Types constants already existin PHP 7.1.0:
https://www.php.net/manual/en/language.oop5.constants.php

Resetting the core version requirement to : core_version_requirement: ^8 || ^9 || ^10 || ^11

This is harsh, need to find another way - new versioning?

johnv → created an issue.

Your solution seems ok:
function foo(?$var = NULL) {}
or
function foo(array|null $var = NULL) {}

However, did you only encounter this one occurrence? I count about 12 occurrences to be corrcted.

It seems we have a problem here: https://www.drupal.org/project/drupal/issues/3505049#comment-15979351 💬 Drupal 11.2 upgrade causes \Drupal::$container is not initialized yet error Active
Explanation here: https://drupalize.me/blog/drupal-111-adds-hooks-classes-history-how-and-...
Core change-record here: https://www.drupal.org/node/3442349 →

Please insert the following line in the office_hours.module file and reprot back:
include_once 'office_hours.theme.inc';

My #17/#18 was a response to #13, waiting for more (IIUC modules).
I think this problem is not module specific, since it is playing by the boom, until an upgrade to D11. 1 was performer.

@ghost of drupal past, can you explain the reasoning of your patch? Also, in my problem, I have theme hooks, not _alter() hooks.

Itis a wild guess, but Drupal 11.1 Adds Hooks as Classes mentions "In Drupal 11.1, the logic for calling a function based hook is now in ModuleHandler::legacyInvoke()".
So the introduction of that might be the culprit.
Anyway, this seems to be an error.

The office_hours.module.file.now contains this one line, and the theme file seems not to be loaded.

// Include file, avoiding container error during upgrade.
if (\Drupal::hasContainer()) {
  // Add theme.api.php hooks.
  \Drupal::moduleHandler()->loadInclude('office_hours', 'inc', 'office_hours.theme');
}

The office_hours module suffered/suffers from this problem.
See
🐛 Drupal 11.1 Crash Active and follow up Child issues.

The module included 2 files from the .module files itself, after removing that, and including all books in the module file, a Follow up was encountered for a nested included. Removed that as well.
Now, the 2nd theming file is still not included, as reporter by a user.

Should we then move this to the widget and formatter class files?

Or find some example in another module.

Yes, you can do this.
Just add an additional non-exposed filter and select 'Is not one of' 'Anonymous'.
(Indeed, the exposed filter might still expose the irrelevant user roles).

I guess this very old issue can be closed.

OP implies that the " Remember the last selection" option is in play. But the Problem motivation does not say that explicitly.
That means this is a duplicate of 💬 Using "Limit list to selected items" on exposed filters not working properly Active
If not, the issue must be re-opened, and above test script should be completed.

As a summary of the above discussion:
#1-#34 are about the new text proposal
#28 contains the latest text proposal
#39-#44 are about other proposal that better deserves its own issue, if still needed.
#40 expresses some thoughts about current behaviour
I tested in D11.1 the behaviour of the (exposed) filter operators and options: Whatever the limit/expose settings, the values that are set in 'Filter criterion' form, are directly applied to the view, when a user calls the view.

Issue summary is updated to standard format.
Issue moved to views_ui.module.

Regarding the text proposal, I find the additional lines hard to understand. Or even: I do not understand them at all.

As an alternative, let us compare with the other option:
[ ] "Limit the available operators" = "Limit the available operators to be shown on the exposed filter."
Then 'our' option would just be:
[ ] "Limit the available options" = "Limit the available options to be shown on the exposed filter to the ones selected above."
This is what is proposed in attached patch.

Thanks. Committed, with some more code removed.

It would be helpful if the js is identical for both cases. I tried adding class = "js-office-hours-operation-$action", but that lead to the last operation having 3 such classes

I can, and did, as a maintainer.

I only recently found out that crediys do no oly go via commits, but also the issues themselves.

Hi Andrews, do you want to reppen this issue?
I have changed the relevant code fase today.

Regarding the 'action buttons', that apparently are not supported.
In another module, I have the following form settings:

    $form['basic']['options'] = [
      '#type' => 'select',
      '#title' => $this->t('How to show the available...'),
      '#required' => FALSE,
      '#default_value' => ...,
      '#options' => [
        // These options are taken from options.module.
        'select' => $this->t('Select list'),
        'radios' => $this->t('Radio buttons'),
        'buttons' => $this->t('Action buttons'),
        'dropbutton' => $this->t('Drop button'),
      ],
      '#description' => $this->t(Decide which is the best way to show them.'),
    ];

But perhaps you want the 'button' inside a 'select' list?

Thank you ,
whenever you create a patch/MR for an issue, you may set the issue status to 'Needs review'
it seems your MR contains too much code.

These changes in buildOptionsForm(&$form, ..) are not necessary, since $form is returned by reference.

 core/modules/views/src/Plugin/views/pager/Full.php | 1 +
 core/modules/views/src/Plugin/views/pager/Mini.php | 1 +
 core/modules/views/src/Plugin/views/pager/Some.php | 1 +

You will not need to create/change buildOptionsForm() for the follwing, since they will inherit from SqlBase

core/modules/views/src/Plugin/views/pager/Full.php
core/modules/views/src/Plugin/views/pager/Mini.php

So, you will only need to duplicate the changes from Some.php to SqlBase.php
core/modules/views/src/Plugin/views/pager/Some.php

I will now set the issue status to 'Needs work'.

OK, leaving this for now.
The code base is rationalized, so that the differences between codebase and pathc are minimalized.
Chunks from the patch have been committed to codebase.
Classes are added to the operation, they were omitted in the patch.

Please see attached files:
- the patch contains the changes to enable dropbuttons. 'clear' action does work. something is wrong for 'add' and 'copy' - I believe they did work before.
- the 'remaining' text file are the chunks from the patch that have not been used, for your reference.
- there is no setting to switch the UX, yet.
- see comment #32 about the 'action buttons'
- see comment #14 for UX and an older patch.

Above patch factors out the $title and $weight variables, so the button can be easily inserted by adding the following lines after each definition of $title (already in current code):

        $title = sprintf('<button type="button" class="button" data-drupal-selector="clear">%s</button>', $title);
        $title = Markup::create($title);

However, that adds Action buttons, taking up unreasonable amount of space in my Olivero/Claro theme, so dropping that for now, and concentrating on pure dropbuttons.

johnv → created an issue.

johnv → created an issue.

Moving slowly towards perhaps applying the patch, by removing noise.

The mentioned const definitions were already changed, but I will create a separate issue for updating all const definitions, raising the php and drupal version bar.
In priciple, my doubts expressed above and in 📌 Fix accessibility issues in form Active still exist.

You did update to the dev version, didn't you? because indeed, it was not added to the view in v1.21.
I added in the dev- version, and I thought it wasin this issue, but I do not see the commit. so prbably n another issue.

I guess there is no interference with other modules?

In the field formatter, in the 'Exception days and Seasons' section, under 'Title for exceptions section' (helptext: Leave empty to display no title between weekdays and exception days.), did you fill a date?

When you check the page with 'Inspect element' of [F12], do you then see an element?

Ah, but it seems you have not set any exceptions at all.
Please maintain exceptioneel in the future, and make sure they are in the horizon that you can maintain in the formatter setting.

I use out-of-the-box Oliver and Claro themes from Drupal 11.

I am open for a contributed patch.

@peter majmesku, thanks, your solution seems to help when you have multiple pagers on a page that get synchonized unexpectedly. There are 2-3 other 'pager' issues that hint to this solution.

@segiur, that might indeed a solution for some cases.

johnv → created an issue.

The patch still is valid on D11.1

The problem occurs and is solved in both cases: with Date filter 'date' option and with 'offset' option. Updating summary.
A test is added, but #20 is still relevant.

Updated the summary test script with:
"-- for better analysis, you may add 'Global: Result summary' to the header section.
"-- for better analysis, you may add 'Global: View result counter' as a field.

Added 'Exposed filter' vs. 'Exposed form' explanation.

I guess there is a misunderstanding here.

From 'web\core\modules\views\src\Plugin\views\exposed_form\ExposedFormPluginInterface.php'

Exposed forms are used for filters, sorts, and pager settings that are
* exposed to site visitors. Exposed form plugins handle the rendering,
* validation, and submission of exposed forms, and may add additional form
* elements.

So, for example rendering the list box on an exposed filter.

But it does NOT change the output of the query. For that you need the filter/sort/... handler, that IS called in postExecute().
Regarding #18, you need to implement hook_views_post_execute() or hook_field_views_pre_render() in your Views filter plugin.
However, doing that, you will encounter query result problems, as summarized in 🌱 [META] Fix pager bug reports Active .

The OP is confusing to me on several accounts
- the expected outcome is in +/- 3 days, but the actual results are in years
- the printscreen shows that 'An offset [...]' is selected, instead of 'A date [...]'.

I my test, when selecting
- 'An offset [...]', I need to set '-7 days', to '+1 day'
- 'A date [...]', I need to set '20241231' to '20250303'
IMO that is OK. I can imagine a view with changes in the last week (using offset).

Of course the widget is very basic/not acceptable for ordinary users.

So, this issue still 'Needs issue summary update'

I understand correct that the issue only works for Anonymous users?
Indeed, there are 2 core cache modules:
- dynamic_page_cache works for authenticated users
- page_cache works for Anonymous users, and NEVER ends the cache. You should disable the cache on this view.

Please check if the problem occurs also when:
- ajax is disabled
- authenticated user uses the View
and update the title/summary if this is the case.

This sounds like an identical/similar problem as 🐛 Pagination not working correctly in AJAX view with exposed filters Needs review , which prposes a solution in core/modules/views/js/ajax_view.js
Is it?

Please confirm that this issue is about 'Pager shows empty/nonexistent page N after applying an exposed filter, so new result has And that it is an identical/similar problem to 🐛 Views pager doesn't return to previous page when deleting the content from last page Needs review , which has a solution in core/modules/views/src/Plugin/views/query/Sql.php.

Should both use cases benefit from the same solution?

I assume the problem only exists in Views preview - the same view does work correctly when saving the view settings, and visiting the view page?

This fairly old discussion discusses the same pagination problem (with post-sql result filtering) that people experience in the View module. Therefore, I am setting up a plan 🌱 [META] Fix pager bug reports Active on Views.module.
I am not so much into JSON use cases, more into Views, and I am not aware of the developments in jsonapi regarding this topic.

My question here: I would assume (having a headless Drupal ITMT) that both jsonapi and views use a common core code. However, Views module uses e.g. \core\modules\views\src\Plugin\views\query\Sql.php , so apparently no.
Does that mean that any improvements on pagination should be developed independently?

Is there any progress in jsonapi regarding this topic?

Sorting multiple issues with "Pager option 'Items per page' with value 0" alphabetically.

The following issues are duplicates, having competing solution proposals:

• 🐛 Views incorrect display with filters, table and full pager Active adds 'margin-block-end'
• 🐛 Olivero pager template creates additional grid columns Needs work removes 'layout--content-medium'
• 🐛 Using 'Paged output, full pager' changes view table display Active (without patch, but contains nice screenprints in #3 and #5)

I cannot judge which solution proposal is best. I guess the second one.

Issue summary is now updated with better screenshots and steps to reproduce, so removing tags.

The following issues are duplicates, having competing solution proposals:
🐛 Views incorrect display with filters, table and full pager Active adds 'margin-block-end'
🐛 Olivero pager template creates additional grid columns Needs work removes 'layout--content-medium'
🐛 Using 'Paged output, full pager' changes view table display Active (without patch, but contains nice screenprints in #3 and #5)
I cannot judge which solution proposal is best. I guess the second one.

I guess the 'Needs subsystem maintainer review' allows the patch to be reset to 'Needs review'.

The following issues are duplicates, having competing solution proposals:
🐛 Views incorrect display with filters, table and full pager Active adds 'margin-block-end'
🐛 Olivero pager template creates additional grid columns Needs work removes 'layout--content-medium'
🐛 Using 'Paged output, full pager' changes view table display Active (without patch, but contains nice screenprints in #3 and #5)
I cannot judge which solution proposal is best. I guess the first one.

Settings this a duplicate, since the others have a patch.

Not sure if this is an 'ajax system' issue, or an 'Oliver theme' problem.

This is a duplicate of 🐛 Views incorrect display with filters, table and full pager Active and is a problem in Olivero theme. It can be reproduced without layout_builder, too.

#20 shows the relevance of 🐛 Make usability better for "Link display" setting Closed: outdated

"It should also instruct the user to create a new display to get more options here. "

I was going through the "More link" issues, and I could not reproduce, on my simple view with only 1 page display.
Then, somewhere I was encouraged to add a Block display to the View. Now the "more link" appears on both the Block display and the Page display, but the "Link display" option is only showing on the Block display. I am confused.

Now I also understand why people state (on issue ...) that the unconfigurable 'More link' is useless on Page displays, since it point to the display itself.
(Alphabeticaly ordening the 'More link' íssues.)

The issue 🐛 Implement constraints for Pager config Active contains a directive to use constraints, rather than if-then constructions.

if (is_null($value)) {$value = '';} can be shorter with $value ??= 0; . Setting 0 since we expect integers.

The issue 🐛 Implement constraints for Pager config Active contains a directive to use constraints, rather then if-then constructions.