🇫🇷France @fgm

@anybody : awaiting a return from @newswatch since they appear to say it doesn't work for them, but I do not see how that can happen so we need more info.

@anybody: seems your sentence is missing a word ? Maybe it was "mark" ?

@newswatch you will need to provide more details about your configuration, possibly a a URL, to receive help. Without that we cannot know what does not work on your site.

First, can you reproduce the problem on a new site with just D11 core and statistics ?

@catch Do you have the reference of any issue of which this might be a duplicate ?

I agree that the mechanisms you mention may be part of the solution to the problem, but they are not sufficient on their own and do not reduce load as much as this would unless adding a lot more off-Drupal configuration.

If this issue was marked as a duplicate only because of these mechanisms, it does not seems like it is actually a duplicate, and would merit being pursued on its own.

@anybody : I'm not in a position to take up maintainership of one more module.

No, I thought you were doing it so didn't look further. I might have some time this weekend.

fgm → created an issue.

Not forgotten, but still no fix upstream in #3438843: Problem with eslint extends → six months later.

Seems like Rector now handles the declared constants. And there is no remaining issue: the warnings reported since June are only the deprecations announced for 8.x-1.x features going away in 8.x-2.0, nothing related to core, so marking fixed.

Maybe it's bikeshedding, but terms I usually here in this context are a bit more general: rather than "dev"/"prod" the distinction tends to be "build" vs "run", which may be more explicit: it's either an environment in which devs intervene, or one on which they (usually) don't.

Also, as to where, the most logical location for something which is deployment-dependent seems to be settings. The bigger plus is that it can be updated without downtime by a single file change. The minus being that it conditions modules and services availability. "Run" deployments usually have dedicated cache servers, queue servers, proxy, CDN, which may not be enabled on a "Build" environment, and that means differences from the composer.json up, with different resulting modules and configurations, which is not something that something in settings can support.

The way I've been doing it on client projects since Drupal 8 pre-alpha has always been to expose this in the composer extra information, so it's available from the build step, AND use it to generate two per-environment settings using (Twig) templating, so all scripts and composer plugins run relative to that environment. Deployment commands, being "build", use the "build.settings.local.php" target, while everything after build (hence run) uses the "run.settings.local.php" target, switching being performed because the "settings.local.php" is just a symlink that can be updated atomically.

Similar conversion done for Features in #2913651: Drush 9 Incompatibility → , if it can help.

Cool. It seems that solved your issue ? If so, set the issue status to "Fixed" (not "Closed").

If you do not have a profile created, that config is not instantiated , and nothing is noticed. You need to create a first profile (forgot that in the steps), which will contain the undefined keys.

Maybe merge 🐛 Config Schema is missing the Notify schema Needs work before someone else bumps into this too.

Suggested patch for review. Fixes the problem for me.

fgm → created an issue.

OK, now I see the problem in your latest paste. The error message says require_once(autoload.php): Failed to open stream: No such file or directory in /www/wwwroot/idbip.com/web/modules/statistics/statistics.php on line 25; PHP message: PHP Fatal error: Uncaught Error: Failed opening required 'autoload.php' <em>(include_path='.:')</em> in /www/wwwroot/idbip.com/web/modules/statistics/statistics.php:25 (emphasis added)

This means PHP is only looking for files to include in the current directory, no other one. The statistics.php file starts by a chdir('../../..'). But your module is located in /www/wwwroot/idbip.com/web/modules/statistics/, not /www/wwwroot/idbip.com/web/modules/contrib/statistics/ as it normally should be. So that chdir changes the current directory to /www/wwwroot/idbip.com/, and the next line $autoloader = require_once 'autoload.php'; looks for autoload.php in that directory, although it is actually in /www/wwwroot/idbip.com/www instead.

I see from your screenshots that you placed all your contrib modules under /www/wwwroot/idbip.com/web/modules/, but they should be under /www/wwwroot/idbip.com/web/modules/contrib/ instead. In most cases, that doesn't matter, but Statistics is using a custom front controller which needs to locate the Composer autoloader itself instead of relying on core settings (for speed reasons, if you want to know).

So the correct fix is to

• go to the project root cd /www/wwwroot/idbip.com
• uninstall at least Statistics so that core does not keep track of where it is drush pmu statistics
• create the missing directory mkdir web/modules/contrib
• move statistics there mv web/modules/statistics web/modules/contrib
• re-enable Statistics drush en statistics

That should fix your problem.

More generally, all your contrib modules should be in that web/modules/contrib directory, but it may be complicated to move them and most modules do not really care anyway. Just keep it in mind for the next ones you install. If you install with the standard Drupal composer install process → , your composer.json will include the necessary installer-paths configuration so that any module installed using composer require drupal/somemodule will be properly located, as well as any contrib theme or library.

Interestingly, I noticed that this works on my mac, but when I deploy the exact same site on Linux and import the exact same configuration, the error reappears. expand_nowrap remains unknown to the schema, although the module sets that key from the UI, and it then gets exported as an int (0/1) instead of a bool, and throws the error in config inspector. But not when taking the DB and config and deploying them on a mac. PHP 8.3.11 FPM in both cases.

fgm → created an issue.

OK. so it looks like that install is missing the autoloader files. Your server is configured to use PHP-FPM on a UNIX socket. Looking at the original page, apparently https://www.idbip.com/peugeot/peugeot-2008-review-design-features-perfor... I see that you put the statistics.php URL behind a CDN, which will you don't want to do, to prevent caching since the goal is to count hits.

But anyway, the CDN says the upstream response has length 0, which is caused by the error you mention in #7. Anyway, at that URLs, the page tries to load statistics.php from https://www.idbip.com/core/modules/statistics/statistics.php, meaning you are still using core Statistics, not the contrib version, which would load from https://www.idbip.com/modules/contrib/statistics/statistics.php

Regardless, this errors telles you that you need to ensure your Composer deployment is complete, meaning that there should be a /www/wwwroot/idbip.com/vendor/autoload.php file. Can you see it ? Or do you have /www/wwwroot/idbip.com/core/vendor/autoload.php instead ?

That seems to apply to Drupal core: there is no drupal module name and indeed one gets that kind of error

No : since D8, you no longer need a module like this one: everything needed is pretty much already in core.

For Drush, if you installed your project using composer, it's just a matter of doing composer require drush/drush. After that, a Drush command will be in your vendor/bin/ directory. From there you can either edit your $PATH variable to include that directory or use it with an explicit path like ./vendor/bin/drush <command>.

Drush does not require any configuration: it works by default. It is usually best not to use a global version, but a per-project version like I just described, because multiple projects on the same machine may need different versions.

Good conclusion :-)

The problem is that you really should be running cron on a regular schedule: that is one of the expectations of hook_cron. Typical rate is once a day, ideally just after midnight in your timezone, so that reset can be performed at what looks like midnight for your users/admins.

I would advise setting a crontab like 0 0 * * * /path/to/project/vendor/bin/drush core:cron and no longer triggering it manually. Why do you have to run it manually at various points in the day ? This is not typical Drupal practice.

You probably want to submit it as a merge request: patch format has been deprecated for quite some time already.

100% for removal of 9.x compatibility. Keeping contrib compatible with dead versions just helps prolong the suffering of those still running them and makes code worse for those maintaining modules.

Actually, this has removed the wrong tabs, but the /list-changes/(module) pages are still undiscoverable from /list-changes

The "previous major" fail is because Drupal 9 (RIP), didn't have the DeprecationHelper anyway so we cannot have a version for D9 to D11.

@grevil I added a workaround for that default parameter value, but I'm not a big fan of it. Any better suggestion ?

Regarding timezone, AFAIK you need to reboot the server for the change to be taken into account.

Regarding statistics, there should not be any technical difference between core statistics in Drupal 10.3/10.4 and contrib Statistics 1.x: the changes only come in 2.x versions and in extension code.

Statistics Counter is not really supported, but seeing how it works should not impact daily resets.

That reset time is strange, though: it looks like it is entirely unrelated to your timezone. Which raises two questions:

• Exactly how do you run cron ? Is it just the "Automated Cron" module in core ? Or something else ?
• If you cannot run Drush commands, run this SQL:
  

  SELECT value FROM key_value WHERE name = 'system.cron_last';/code> : this will always give you the last time Drupal cron was run, which should match your reset time if you only run cron once a day.</li>
    <li>Then <code><code>SELECT value FROM key_value WHERE name = 'statistics.day_timestamp';

  : this will give you the time Statistics daily count was actually reset

The way Statistics resets the daily counts is by running code on each cron, which will check if the current time is more that 24 hours later than the previous reset time. If it is, it will reset all day counts to zero.

This means that if you want real-time-based daily resets, you want to run cron exactly once a day at midnight, not less. If you have very little traffic and you are using Automated cron, e.g. you only have anonymous visitors served from cache, then cron will not trigger on these cached pages, and you may get updates only when someone hits a non-cached page.

So, again, how are you triggering cron ? You can find more info on Automated Cron at https://www.drupal.org/docs/administering-a-drupal-site/cron-automated-t... →

AIUI, these code style changes were originally added just to make the tests pass, not for any technical purpose. Seeing how tests are now passing, I think it would be good to release this to unblock at least D11 users.

Users of D10.3 and of obsolete versions do not have any more requirement to upgrade XMLSitemap than the core versions which they did not upgrade, so that should not be a problem for them.

Tried the Deprecation Helper, seems to work just fine in 10.2.7 and 11.0.1

Not sure I understand your last comment: you said it should have been reset between 17:00-18:00 and it was already reset at 17:58, which is within 17:00 - 18:00 ?

This being said, I notice the data command is returning a non-UTC time, and ISTR that it is generally recommended to have servers use UTC time, adjusting per-user time with the TZ environment variable in their profile. And there is something else: 11:05 CST is equivalent to 17:05 UTC, not 03:03 UTC. See e.g. https://24timezones.com/fr/difference/cst/utc : But I see that Asia/Shanghai is /also/ called CST so there may be a confusion on your system between the generally used US CST and the Asian CST. I would suggest that you set your Linux to use UTC in /etc/timezone instead of a local timezone. Your php.ini already contains the Asia/Shanghai setting so should be alright.

Beyond that, your statistics.settings.yml is incorrect, not enabling views counting, so I think you may have sent the file found in the module instead of the one in your active config. Do you confirm that ? If you haven't installed drush yet, you can check active config values with devel module, at devel/config/count.

@lukas_w after considering options, I will not lower the requirements to a version not recommended for core. I understand it may be a bit more troublesome, but the security and bug issues involved with older versions is not worth it in my opinion.

OK, so I took a look at your nginx configuration and, although I'm not familiar with it, it looks like it might work.

What happens when you specifically navigate to https://(yoursite)/core/modules/statistics/statistics.php if you are using Drupal 10.3 or earlier with core statistics, or https://(yoursite)/web/modules/contrib/statistics/statistics.php if you are using Drupal 10.4 or later with the 1.0.0 version of Statistics, installed in (docroot)/web/modules/contrib/statistics.

Specifically, use curl or httpie to perform that command and provide the headers and body of the response (truncated if it's a html page).

OK, this will need some clarifications so that I can reproduce the problem. Can you detail:

• The result of the command date; date --utc on your server
• The result of the SQL command SELECT * FROM `node_counter`order by `timestamp` desc limit 10;</li>
• The result of the command drush sget system.cron_last on your server
• At which time in your timezone you observe the counters being reset
• If you have any cron module active, like core automated_cron, or contrib like ultimate_cron, Elysia cron, ...
• If you run any cron task from your operating system, like a crontab task, and if so its schedule

Additional info may turn out to be helpful later if the questions above do not allow fixing the problem.

• OS version
• The Drupal version
• The database server version
• The PHP version and SAPI (apache2, fcgi/fpm, cli, ...)
• The Apache configuration, especially vhost file
• A copy of the web/.htaccess file if it has been modified from the distribution (replace sensitive parts before sending)
• The php.ini (take care to replace all passwords/keys before sending it)
• A copy of the /admin/reports/status/php page (replace sensitive parts before sending)
• The statistics.settings.yml file as it is in your config directory

But for now, let's start with the first set.

Patch removes the error, as show in that screenshot.

fgm → created an issue.

Also, it does not show the synthetic dev version numbers for me, giving the branch name instead, as in this screenshot.

Not sure whether that's related, but even with the module enabled on D11.0.1, I do see the contrib updates, flagged as invalid for MR branches, but no core releases. It looks like it could be related to 🐛 Error when there is no Drupal project name.info.yml file Needs review , because there is no `drupal.info.yml` in core, but that's just an idea.

Thanks @balu_ertl for having worked on this. Do you need help with something so we can get that release ?

I wonder: should I be expecting any news on this, or just forget about rector since the module is already compatible with D11 anyway and the ugprade bot keeps pushing nonsense on 📌 Automated Drupal 11 compatibility fixes for g2 Needs review ?

Could have been avoided by some documentation, see #2264047: [meta] Document service definition tags →

@chx just made me notice that 🐛 False positive in twig scanning, with reproducer Fixed is a consequence of this.

With help from @Gábor Hojtsy, I found the issue:

• Extensions do not require a tags: [{ name: twig.extension }] property on the service defining them to work with core
• They do require it to be autoregistered during scanning, and possibly other situations
• The original module and this demo module did not contain the tag on the extension service

So there is this discrepancy between the way things actually work in core, and the way they are scanned, which may or may not be a bug in core or in scanning. But the fix is simple: just tag extensions and they will work in both situations.

IF you look at the project page of Statistics Counter, it says "No further development No longer developed by its maintainers.", so it looks like you might want to reconsider your use of that module, or apply to take over maintainership: it's a very small, very simple module, so it might be something both doable and useful for you to do. Would that be of interest ?

Also, the second screen cap shows that there is indeed no syntax error being reported : the filter is invoked and returns the expected values.

Since you appear to suppose that the module might not be installed, here is a zoomed out copy showing it is indeed installed.

This probably means that the php timezone for the server is set to your local time instead of UTC. Can you check your php.ini ?

OTOH, upgrade_status still reports three instances of error Call to deprecated method renderPlain() of class Drupal\Core\Render\Renderer. Deprecated in drupal:10.3.0 and is removed from drupal:12.0.0. Use Drupal\Core\Render\RendererInterface::renderInIsolation() instead.

But these are only a problem for D12 migration, so should not be holding back the D11 release.

fgm → created an issue.

Cool.

Hi @Idflorin : I'm not ignoring you but Nginx is not (yet ?) an officially supported server for Drupal, although it is widely used. As mentioned on https://www.drupal.org/docs/getting-started/system-requirements/web-serv... → some security features are only provided for Apache, which is why I never use it even for huge sites, so cannot help you myself.

You might want to track ✨ Provide documentation/default server block for Nginx server. Needs work which aims at providing a reference Nginx configuration, and possibly ask people discussing in that issue.

This is to reference the node from the context of your template, providing the node context to the template, as explained in e.g. #2992921: how to get drupal_token arguement/context → .

In order to maintain DB size to reasonable levels, the statistics module is not keeping any kind of history in the Drupal DB.

As described in the Plan at 🌱 Plan for Statistics 1.x Active , this is a stretch goal, and currently implemented by additional non-Drupal code using external databases best suited to the kind of volume needed by analytics.

This is actually part of the Plan issue: Statistics is expected to provide basic data collection services for instantaneous statistics at low cost, and provide the statistics collection point for third party "ecosystem" software providing extra features while not exposing the actual Drupal DB to them for PII protection reasons.

This patch is looking good enough. This being said, since D9 has been EOL for 9 months and we are targeting 5.x, we might want to remove D9 from the compatibility clauses in the .info.yml and composer.json files, IMHO.

Upstream issue 📌 Automated Drupal 11 compatibility fixes for robotstxt RTBC is now fixed and RobotsTxt 8.1.6 has been released with D11 compatibility: https://www.drupal.org/project/robotstxt/releases/8.x-1.6 →

Looks good enough to me, although we probably should remove 8.8 and 9 from compatibility since they have been EOL for a long time.

Also, you might want to present that patch as a merge request, as this will enable anyone to use it in a composer workflow until the fix is merged.

fgm → created an issue.

FWIW, this module is blocking use of webprofiler on D11.

@lussoluca, would you be open to merging a release if I review/complete this issue ?

fgm → created an issue.

fgm → created an issue. See original summary → .

Is anything still blocking release ? Can I help ?

You're 100% right. Even more so now that 11.0.0 has been released and no longer contains statistics.

Updating issue to current Statistics release.

Note that this issue is about the contrib statistics project, not statistics in core, but the link you mention https://github.com/drupal/drupal/tree/10.3.1/core/modules/statistics is about core.

Makes sense. Smallest interfaces are the most useful ones, since you can always extend interfaces but not reduce them.

@lukas_w any reason why you ask to lower php requirement when it is already 8.1.6 ?

@jordan.jamous thanks for the reroll. Can you convert the path to a MR, since the old bot no longer runs and we have a working Gitlab CI integration ?

Thanks. As you can see, this MR fails https://git.drupalcode.org/issue/mongodb-3458044/-/pipelines/213633/test... so you now need to fix it.

Excellent: thanks for taking the time to let me know.

@sourabhsisodia_ can you also update the .gitlab-ci.yml to run the checks on PHP 8.4 ?

Also note that this is not just a base module issue, but applies to all the modules in the project. It's just associated to the base module because on d.o. one can only select a single component.

fgm → created an issue.

I know this issue is "won't fix", but adding it here for anyone trying to use coverage attributes in PHPunit 11: the

#[CoverFunction(string 
$functionName)]

attribute is only available at the class level, not method level (WTF ?), per https://docs.phpunit.de/en/11.2/attributes.html#coversfunction so it cannot replace the @covers annotation.

Still present with Drupal core 10.2.6 and Drush 12.4.3.0, PHP 8.3.7.

Downgrading to PHP 8.2.19, the issue goes away for me.

@O'Briat Thanks for the heads up !

Makes sense, since it's just a few common values, so we validate standard markup, then ?

OK, so it's just the tiny extra markup weight. Probably worth it ?

If we go the Attribute route, I suggest we use composition instead of inheritance for future protection. With PHP not supporting multiple inheritance, should the Attribute class get child classes, we would be in a diamond problem situation if we inherit that class. Also, in recent years, Drupal core appears to have started to embrace the trend of final classes/methods/fields. Composing Attribute instead of inheriting from it offers us two advantages:

• it protects us from that kind of changes
• it saves us from the temptation of using non-public properties/methods

I'd even suggest creating an AttributeInterface currently made of the public methods (no public fields) of the Attribute class, and composing that instead of the class itself, for even further protection.

There is a tiny downside in that it makes the markup just a tiny bit heavier. It would be worth checking whether it is parsed at exactly the same speed, or if there is a measurable difference, although even if it is measurable it might not be very relevant.

Fixed in today's HEAD.

fgm → created an issue.

As I mentioned, if you do not actually view a node during a given day, the daily counter does not reset. It is actually the count of views on the last day there actually was a view.

Does it not reset if you actually view the node another day ? If so, can you provide a means to reproduce the issue, because this is not what I observe on my own sites.

AFAICS this means your PHP cannot see your MongoDB server.

Since your phpinfo() shows the extension is installed in your PHP, the likely culprit is the DSN you are using localhost:27017.

Did you copy and adapt the example.settings.local.php provided by the module to your actual topology ?

Try to enter the container in which you are running PHP (possibly the same one as apache) and run mongosh to check if it can indeed connect to your mongodb server. I suspect you need to use the name of the container instead of localhost.

Note that, albeit different, this is related to ✨ Provide option to replace all occurrences of a URL Postponed: needs info .

Not strictly against doing this, but it raises a number of security issues around escaping content which is an an unknown parsing context instead of being only in restricted attributes on specific elements.

Do you have a plan about how to it safely ? Consider that URLs may happen in text nodes, in HTML comments, in CDATA or PCDATA, in embedded JS, in CSS, etc. And all of those have different parsing rules.

I'm not convinced this can be done safely in all these contexts while maintaining a reasonable complexity level.

Alternatively, we might want to enable specific opt-in contexts, say for example the src attribute on link elements within the page head. Would this be appropriate for you ? If so, do you think you could imagine a UI for this ? Just a wireframe would be enough since we use the admin theme anyway. I'm not good at UI design at all.

Also, I think this could be at the global level, possibly overridable per-format, as envisioned on ✨ Need for global settings - reduce Postponed: needs info

fgm → created an issue.

Merged to HEAD.

fgm → made their first commit to this issue’s fork.

Completed, thanks.

This version does not yet run the unit tests, AFAICS, so that needs to be added.

Fixed in today's HEAD.

fgm → created an issue.