The new page still needs to appear in the parent page menu : Installing Drupal →
That seems great, I'll give it a try
This page is not clear and use very confusing terms specially about "pdo" : that is both "mandatory" or "to be uninstall".
The page should make it clear for each database type: the minium modules to enable (dot so) in the php.ini file and how to install the matching module for each OS.
Hi,
We could use a link to your .vscode folder https://github.com/webksde/ddev-vscode-devcontainer-drupal-template/tree...
We could start a suggestions "curration" here in the comments, honestly I'm new to Vscode so I may not have picked the correct one.
Here's "yours" :
"cvergne.vscode-php-getters-setters-cv",
"DEVSENSE.composer-php-vscode",
"dmitrydorofeev.empty-indent",
"esbenp.prettier-vscode",
"jgclark.vscode-todo-highlight",
"mblode.twig-language-2",
"neilbrayfield.php-docblocker",
"streetsidesoftware.code-spell-checker",
"stylelint.vscode-stylelint"
"ValeryanM.vscode-phpsab",
Here's "mine" :
"donjayamanne.githistory", => git tool
"duboiss.sf-pack" => symfony pack (could be useful?)
"eduardgenzora.symfony-service-locator", => does not work, do not ananlyse the services.yml or routing.yml files :(
"formulahendry.vscode-mysql", => add a mysql admin tool to vscode
"george-alisson.html-preview-vscode", => html preview
"ikappas.composer", > recommanded by this page, should be replace by DEVSENSE.composer-php-vscode (more popular) ?
"marcostazi.vs-code-drupal" => Drupal Syntax Highlighting
"mikestead.dotenv" => could be useful when using dovenv files
"mohd-akram.vscode-html-format", => to be challenged
"nadim-vscode.symfony-code-snippets",
"phproberto.vscode-php-getters-setters", => to be challenged
"redhat.vscode-yaml", => Yaml code
"stanislav.vscode-drupal", => recommanded by this page
"thenouillet.symfony-vscode",
So there's no legal issue any more, the core DSFR itself is not "taint" by the GPL?
The limitation about using this theme on a non French government website is still valid?
It's not only about formatting but cover the general Vscode Setup, including debugging and all the useful extensions that could help Drupal development.
Here's my git repo : https://github.com/obriat/vscode4drupal
The extensions file does not install them automatically but provide suggestions (notifications and a category in the extensions UI)
A full .vscode folder with all json files (settings, extensions, launch) should be provided (zip to download or git repo), no?
It should be made clear that the {machine_name}.info.yml filename is the source of the module machine name
This page needs to explain how to setup the Drupal configuration export/import, specially if one uses the suggested config : ../sync
Great idea, writing log to file is quite slow.
But using the Symfony bundle seems a bit overkill, no ? The logging process should the lighter possible, just using a simple guzzle call, a non blocking one if possible (https://drupal.stackexchange.com/questions/296743/non-blocking-http-requ...).
The current "processing rate" could also be displayed to add a clear message, ex:
"This can happen when no processors are clearing your queue, or when queueing outpaces processing. Please first solve the structural nature of the issue by adding processing power or reducing your queue loads. Empty the queue to unblock your system. The current processing rate (@current_rate clearing requests/s) is lower than the queue growth one (@growth_rate new item to clear/s)."
The most elegant way will be a form with a check box to enable or not the auto detection based on reverse proxy. If uncheck, IPs should be input in a text field.
Why not take example on the ZeroConfig Purger?
It does multiple call based on the reverseProxies list:
https://git.drupalcode.org/project/varnish_purge/-/blame/8.x-2.x/src/Plu...
Does the vcl example file for zeroconfig does the same thing ? It works for me since ages.
https://git.drupalcode.org/project/varnish_purge/-/blob/8.x-2.x/zeroconf...
The problem could also legitimately occurred when massive import/update batch are executed regularly.
The module could provide an option that purge all cache (drush p:invalidate everything -y) and empty the queue (drush p:queue-empty) ?
Format code. The "number 3" needs more info: add details about file registration (linked to node id or module, name, ...)
So, what's left :
- Force HttpOnly to false and remove it from the admin form
- Update the MR with the minor fixes from 3308456-30.patch #30
- Change the MR target branch to 2.x (or create a new one if this fix should still apply to 1.x)
What are the prerequisites for using transactions? For example, does the binlog needs to be enable?
Yes, I know but with just two carriage returns all the module now complies with the Drupal standards. If you think it's not needed, I'll revert it.
Phpcs fixed, I also added two minors fixes on CronTest.php
The patch for #3471571 is now live on an production drupal. So far it seems ok.
Could some else tests it and marks the issue as RTBC if ok and close this one at the same time?
The patch is live on an production drupal. So far it seems ok
Could some else tests it and marks this issue as RTBC if ok?
The error is logged with an emergency level (!) which seems a bit overkilled for a simple ban call.
And by the way, Emergency level + rsyslog leads to sending message to all users shells.
*.emerg :omusrmsg:*
https://www.rsyslog.com/doc/configuration/modules/omusrmsg.html#write-em...
I don't remember why but I added this file to my "packaging exclusion list" (along with install.php, readme,...).
Can someone explain me what's the use of this file on a packaged deployed website (updates done only with composer)?
After digging a bit more into pruger I found that "Runtime measurement" is a "duration autodetection" feature :
https://git.drupalcode.org/project/purge/-/blame/8.x-3.x/src/Plugin/Purg...
So it's ok to have errors that pop during the first calls.
IMHO, this info should ba added to the help text of the field and the timeout exception should be handle specifically , do not log under a high value (30s or a multiple of the basic value) or not with the emergency status.
Sorry for the mess, I 'll have to dig a but more, all I recall is that #3293026 doesn't fix a specific case.
I'll try to make a summary
If your Varnish servers are load balanced, it should easier to add a specific rules to your load balancer (filtered on drupal IP + PURGE/BAN method) so it send the request to both all Varnish instances.
So you just need to set the inbound LB IP.
My 2c:
I wonder of this whole cache tag invalidation is not overkill?
It's a mess to configure: adding and setting two modules and purgers, managing a specific queue with processors like frequent cron or (worst) a later runtime, the queue could explode if you massively/frequently update contents, managing a specific varnish config (good luck if it's load balanced), ...
It add a real complexity to your website architecture.
I simple varnish configuration that cache your anonymous pages for 5 should be enough in most of the cases. If your website needs to display fresh information in real time: use ajax or push events API.
The MR is already done, I just added the patch so it can be added safely into compose.json (the MR link could be altered by additional commit, it's still an global issue: https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... → ). I'll edit the message for clarity.
Please test the MR or patch
Here the MR and the patch.
The new token should only be used with the content type application/json to avoid escape chars. Maybe this behavior should be extended to all purger's body?
It should also fix, the todo in buildFormTokensHelp about token auto detection (there a lack of doc bout the core token api).
IMHO none of the tokens should be escaped.
The problem occurs in \Drupal\purge_purger_http\Plugin\Purge\Purger\HttpPurgerBase::getOptions, this function should use \Drupal\Core\Utility\Token::replacePlain instead of \Drupal\Core\Utility\Token::replace.
I stumble on the same issue when trying to provide a new token (see related issue), in my patch I propose a "safe way" by switching to replacePlain only if $this->settings->body_content_type === 'application/json'.
o'briat → changed the visibility of the branch 3373411-how-to-purge to hidden.
The purge everything works, but the tag one needs a patch to provide a new purge token that return a json array.
If confirmed, I'll provide a patch for purge (if the module teams seems it's a legit format).
I got the same problem with daily massive update from external source. May be the Deduplicate Queued Items ✨ Deduplicate Queued Items Active issue could help ?
See also Cache Max Age warning text →
See also "Cache Max Age warning text"
Have a look to the patch of the "Deduplicate Queued Items" issue
This checks values (24h, one month, one year) seem very strange if not dangerous.
$this->config->get('cache.page.max_age') is the value that Drupal use as max-age in the cache-control header of the response send to the client.
This value will be used by reverse proxy such as Varnish but also by the client browser which could not be purged by Drupal.
Could someone explain these choices?
Do you rely on conditional request header (If-None-Match, ...)?
There's some info in \Drupal\Core\Logger\LoggerChannelInterface, but I agree that this item usage (and the other context ones) should be better documented, since it spreads on all logger usages.
This page lakes a lot of info, specially about multi servers: the need of a shared filesystem (nfs) for public:// private:// and tmp://. The concept of loadbalancing (haproxy) and the concept of healthcheck, sticky sessions, the X_forwarded_* headers,...
The useless of the salve database settings.
This page should also point to performance pages and make reference to other scaling concepts: varnish, memcache/redis, syslog logging, ...
It should also provide basic metrics to monitor that could help to determine if scaling is needed, and if so, what kind
Could someone review the page and add it into the menu?
Hi,
I'm using the memcached php module, this client should provide server failure (https://www.php.net/manual/en/memcached.constants.php#memcached.constant...), so if a server is no more available the sharding method is updated and missing keys (previously allocated to the missing server) should be recreated on servers still available.
The performance loss should be punctual and inferior to a single
drush cr
.
But it doesn't seems to be the case: I tested it, I shutdowned one server (on two) and all performances were falling down. Everything returned to normal once the server was back online.
Am I missing something?
Also I don't get the point of using multiple bins and allocated them on specific memcached server/cluster. It looks like micro optimization, the eventual use cases should be better documented.
Add doc about file_chmod settings (and umask).
Place Windows at the end (still used?)
Remove "Summarizing the permissions" section which seems an unrevelant copy past from the D7 doc.
Remove reference to root (which should never be used in our case)
Replace apache by web server where it applies
Add a doc about web doc root
It's a catch 22 situation since it's a good practice to disallow shell access to the webserver user.
@nofue www-data is a convention, webserver create files with owner:group related to the user used to run them which should no be the same user that deploy the application (which need shell access).
Read the "Linux servers page" sections, user, group and permissions are defined here.
The config folder should also be readable by webserver user, since the backoffice could be used to import or make diff with the configuration set in files (or even export/override it)
There will be problems with already running drupal site, since Drupal creates its files/folder with the owner www-data. chown and chmod executed with the user deploy will failed unless executed with root (or a sudoer's command)
Yes , but this page should also give concrete advices on permissions on common folders where www-data needs to write, at least tmp, but also private (and config and translations, ...), followed by a link to the "Security in Drupal" page and folder location tips.
Maybe a paragraph asking to run drush st in order to determine these folders and then applying the two find 770/600 on them.
Also this page should replace "Greg" with "deploy user".
@xaa, agree, there should also be info about other writable folders such as tmp, private, translation and sync. They should be outside the web root and the www-data group should have writable permissions on them (or not on specific environments).
The first one who tests successfully this solution switches the issue to RTBC?
No doc update needed on this module?
@fgm : Baleen just updated their API : https://baleen.atlassian.net/wiki/spaces/BS/pages/194576385/Invalider+vo...
It seems as easy as using the "Generic HTTP Purger" sub module.
Thanks.
Don't forget to add the info on the module page too ;)
Patch #54 generate a segmentation fault if you try to create an folder with an empty name (infinite recursion).
drush ev '$f = Drupal::service("file_system");$dir="";var_dump($f->mkdir($dir, 1));'
Segmentation fault
This bug was introduce by patch 54 on issue https://www.drupal.org/project/drupal/issues/2799635 🐛 FileSystem::mkdir should handle open_basedir correctly Needs work
this part seems to have rewritten in 11.x, can someone check if this is still an issue?
There are other cases that do not trigger recursion but give strange results:
drush ev '$f = Drupal::service("file_system");$dir="........";var_dump($f->mkdir($dir, NULL, TRUE));'
drush ev '$f = Drupal::service("file_system");$dir=" ";var_dump($f->mkdir($dir, NULL, TRUE));'
ls -la web/
drwxrwxrwx 2 www-data www-data 6 Jun 5 15:50 ........
drwxrwxrwx 2 www-data www-data 6 Jun 5 15:50 ' '
I will provide a MR that avoid the recursion, but feel free to propose other checks.
[edit] FileSystemInterface::prepareDirectory => FileSystem::mkdir
Baleen is based on Varnish, a tag based header BAN is in their roadmap
ok, sorry for the confusion (TL; DR 😬).
I think purge should just split tags by 16k chunks and make multiple calls to Varnish/CDN.