Working on this to some extent, alongside ✨ Support adding additional routes for view modes other than 'full' Active , as they share a common base.
Working on this, and to some extent improvements on ✨ Allow disabling a route for a bundle and adding additional routes for view modes other than 'full' Postponed
As found in 2.8.x
Not for backport, continue using patch for 2.7.x and below (Drupal 10 compats)
Remains NW until tag actionables are resolved.
Lets update the title/commit to be more descriptive, rather than "issues".
As found in 2.8.x
Not for backport, continue using patch for 2.7.x and below (Drupal 10 compats)
Dang, 8.1 is the first release to have an extra year of support. If tradition continued it would have had no support around now.
I'll re-enable the supportedness of 2.5.x branch.
I think I'll have to re-evaluate how my projects get supported as adding another PHP variant to support is undesirable.
PHP requirements dont need to necessarily track core, and they dont for this project.
You should be able to continue using 2.6 until you're ready for 8.3.
These are the remaining variable.undefined items that need to be fixed with polluteScopeWithLoopInitialAssignments =false per strict rules.
Note: the changes in the MR are with polluteScopeWithLoopInitialAssignments turned off, as I believe including them right now would be an overall major style change. Instead, we may consider re-working the logic a bit.
E.g polluteScopeWithLoopInitialAssignments disallows re-cyling the assignment part of for ($i=0; $i<3; $i++) outside of the loop. The neatest way of abiding by this configuration, is by changing things to while AFAIK.
The same error identifier, but more since checkExplicitMixedMissingReturn is on
The rules as described by the Github project page as of today:
Require booleans in if, elseif, ternary operator, after !, and on both sides of && and ||.
Require numeric operands or arrays in + and numeric operands in -/*///**/%.
Require numeric operand in $var++, $var--, ++$varand --$var.
These functions contain a $strict parameter for better type safety, it must be set to true:
in_array (3rd parameter)
array_search (3rd parameter)
array_keys (3rd parameter; only if the 2nd parameter $search_value is provided)
base64_decode (2nd parameter)
Variables assigned in while loop condition and for loop initial assignment cannot be used after the loop.
Variables set in foreach that's always looped thanks to non-empty arrays cannot be used after the loop.
Types in switch condition and case value must match. PHP compares them loosely by default and that can lead to unexpected results.
Check that statically declared methods are called statically.
Disallow empty() - it's a very loose comparison (see manual), it's recommended to use more strict one.
Disallow short ternary operator (?:) - implies weak comparison, it's recommended to use null coalesce operator (??) or ternary operator with strict condition.
Disallow variable variables ($$foo, $this->$method() etc.)
Disallow overwriting variables with foreach key and value variables
Always true instanceof, type-checking is_* functions and strict comparisons ===/!==. These checks can be turned off by setting checkAlwaysTrueInstanceof/checkAlwaysTrueCheckTypeFunctionCall/checkAlwaysTrueStrictComparison to false.
Correct case for referenced and called function names.
Correct case for inherited and implemented method names.
Contravariance for parameter types and covariance for return types in inherited methods (also known as Liskov substitution principle - LSP)
Check LSP even for static methods
Require calling parent constructor
Disallow usage of backtick operator ($ls = `ls -la`)
Closure should use $this directly instead of using $this variable indirectly
I've created 🌱 [meta] Introduce PHPStan Strict Rules Active for discussion about introducing PHPStan strict rules to Drupal core.
Regretfully it seems I havnt made my point about the strict project
I could just as well removal all mentions of the strict project, and these issues would be just as valid.
We don’t need to include or evaluate IF we should use strict. Thats not what these issues are about.
A separate discussion on including strict is necessary, but doesn’t need to get in the way of these handful of things.
with level 0 and no baseline - we still have 230+ issues there, over 2 years since the introduction of PHPStan. We discussed to introduce level 2 during the beta window of D11.0, and missed that. No action happened since then, we are in beta window for D11.1 now and will therefore miss that chance here again.
[...] And there's very little focus on that to be honest.
There is nothing affecting or distracting any of the existing PHPstan work. The things that strict covers can be worked alongside normal PHPStan levels: all about defensive coding style. Perhaps regarding core PHPStan levels, its worth having discussions in #phpstan about accellerating/resolving your concerns.
Do we need the package yet? The docs say that if you turn off all the rules, it still turns on stricter options in PHPStan itself; can't we just turn those on individually where required?
Yes, that's it what this batch of issues are addressing. These related issues are not the real strict rules. It’s moreso things that need to be tightened up before the real rules can be applied.
Just looking at the changes in the related issues, they are quite obvious. We don't yet need tooling to enforce them from re-occurring.
IMHO before looking at adding more rules (phpstan-strict-rules has, btw, 'opinionated' rules, that will require discussion to use or not and possibly have coding standards impacts),
And just some 2c, most of my contrib and private projects use strict. From experience, nothing needs to happen with linting ("coding standards/style"). Running strict properly does change the way you write code, for the better, and this isn't something thats enforced by the Drupal Coder notion of linting.
@smustgrave created an outline at 📌 Resolve issues exposed by PHPStan Strict Active
There are about 8 or so issues I'll create, one for each error type.
An issue is to come about including PHPStan strict, with all configurable options set to off (the issues resolved here are not configurable).
This will allow us to resolve the strict issues one by one, in a similar manner to PHPStan levels.
The amount of problems exposed by strict is very very large (compared to these sub-issues), and not otherwise covered by PHPStan levels.
@smustgrave the issue will come for that, these batch of issues that I've created will allow us to add it without increasing the baseline.
There isn't a lot of them, and its easier to solve upfront.
- Many of these are resolving implicit nulls.
- PHP behaviour of return value for
voidis NULL. - Many of these already have explicit documentation that specifies a NULL return value, but NULL is not explicitly returned as the final return value.
- There is one instance of return value not set because the final return is in fact an exception, so
neveris added as appropriate.
This tag is for https://github.com/phpstan/phpstan-strict-rules, which I don't believe is the intent behind adding this tag on this issue.
Core wont fully replace the need for this project, there are features Hux has which core doesnt have and may never get.
Core and Hux can co-exist, there is no need to rush out of Hux.
I'm aware of Rectors in development to convert the low hanging fruit Hux-hooks (i.e. simple `#[Hook]`)s. Stay tuned.
I plan to support Hux for the foreseeable future.
I'll update the issue as thoughts and plan solidify over the coming year or so.
These still might fall in a camp just like base fields do. As they are distinctly non-config derived fields.
Considering lumping "bundle" into the work that needs to be done for "base" fields.
Unfortunately it hasnt come up as a requirement in all these years, code is welcome.
There is already very little support for base fields, per documentation → and 📌 Improve views support for date recur base fields Active .
I assume this is what you mean by "bundle fields" == "base fields".
Code is useful if you disagree.
This may be closed as a dupe.
PR welcome.
As found in 0.2.1
Another +1 to above.
We use this form as the primary way to assign roles in some scenarios.
For example the People page and user list may be disabled, especially in SSO configurations.
Feedback unaddressed.
Should be a MR in 2024.
Expired.
Per #17
Someone with sufficient motivation should move this to its own project.
Expired.
Marking as a maintainer-approved issue.
This does not signify the code/discussion to date are ready.
Thanks, looks like a good change.
I guess there is no coverage, could be added in \Drupal\Tests\date_recur\Unit\DateRecurRlHelperUnitTest.
Seems like not many use it, and there is at least workarounds (getRlRuleset()). So reducing severity.
Perhaps also, an easy fix would be a new column on the listing page @ /admin/config/regional/recurring-date-interpreters showing the plugin ID.
Feedback still unaddressed.
In 2024 we also need MR's. I no longer accept patches.
getOccurrences shouldnt ignore exdates, its passed along in the RRULE in create() at \Drupal\date_recur\Plugin\Field\FieldType\DateRecurItem::getHelper.
A date will only be excluded if the exdate exactly matches the start date of an occurrence. A date might not get excluded, particularly if the timezones do not match.
In your example, your timezone would have to be UTC+4.
If this is still the case, I'm not sure its the problem with DR, as computation happens with in the library.
if it was a problem with this project, it would certainly not be an isssue with the formatter (per your MR), the issue would lie somewhere between DateRecurItem-DateRecurHelper-Helpers.
If your field happens to be date-only, then its probably: 🐛 EXDATE not excluding dates in only-date recurring fields Active , where exdates would have to be MIDDAY.
No significant progress, closing.
Expired.
There is nothing actionable here.
If someone wants to provide a recipe (blog post?!) to do so, please feel free to post a comment. It will not however become a part of the project.
Maybe the time should be set to midnight (first second) of the day in \Drupal\date_recur\DateRecurOccurrences::massageDateValueForStorage.
I don't recall why it is midday.
Expired.
I cant reproduce failures on sorts.
E.g view
Rel: Node -> Occurrences
Sort: Dr Start
works as expected.
Still necessary
Still would be nice to have.
Expired.
Still would be nice to have, but not concerned if there is no demand.
Still necessary
Preferred to implement in:
Custom widgets, or custom formatters
Please reopen if still an issue, with code workarounds/fixes if possible.
Could be better still..
This is probably still necessary.