Audean Wiki

This is an old revision of the document!

• How to use modules or themes not yet available on Drupal 11 with Composer by Frederic Marand (2025/01/03 17:43)

  How to use modules or themes not yet available on Drupal 11 with Composer Frederic Marand Fri, 2025-01-03 18:43 Computing PHP Drupal tips and tricks DRUPAL-10 DRUPAL-11 The problem Let's face it, with the velocity of major version upgrades in Drupal having increased a lot since Drupal 9, many projects - both themes and modules - do not yet have releases for Drupal 11, or even Drupal 10 for some of them, although they may have automatic compatibility patches / issue forks ready to be committed for months. But, alas, just because they do not declare Drupal 11 (or 10) compatibility in their composer.json (or they don't have one yet, looking at you Bartik), composer require with a patches clause won't work because Composer checks for compatibility without the patches. So how can we use all that perfectly ready code that doesn't have a correctly labeled release ? The classic solution: forks External forks For about a decade, one solution has been to use a project fork. You could fork a Drupal project on a Github / Gitlab repo of your choice, declare it in the <repositories> section of your composer.json, and adjust the release version for standard Packagist releases, or even plain Git versions. That was a reliable solution, but with two related issues: the need to even understand that mechanism, and the fact that the versioning would no longer be generated by http://packages.drupal.org/8 aka the Drupal Composer facade, meaning your forks had to include a correct composer.json file, which does not always work as one would expect due to some magic in the facade, which would generated some exotic release identifier based on the extensions's *.info.yml files. Plus, obviously, the complete disconnect between the original and fork, meaning a need to regularly sync them by hand. Useful, but not great. Enter Gitlab-based Drupal.org: issue forks At some point, though, Drupal git hosting was eventually migrated to Gitlab, and with it appeared Issue forks. For all the naysayers not even accepting that this could exist, it really means that with for each issue on which a patch would previously have been generated, and rerolled before being eventually merged, there would now be a completely independent fork, persisting after the issue was closed. And that suddenly made forks much more practical : at that point, you would still update the <repositories> clause in the composer.json file for your project, but that would now point to the Drupal Gitlab fork for the issue for which the patch was to be applied.
• Avoid gettings your Gogs instance hacked after CVE-2024-39930 by Frederic Marand (2024/07/09 12:46)

  Avoid gettings your Gogs instance hacked after CVE-2024-39930 Frederic Marand Tue, 2024-07-09 14:46 Computing security If you are using the Gogs git server and just apply updates automatically without Reading The Fine Manual, your server automatically became vulnerable with the 0.13 releases. The problem In that version config section [service] was removed, after having been deprecated in the 0.12 releases, in which it was renamed to [auth]. If you did not update your config fields, the update switched your config to enabling auto-registration and other things you may not want. Specifically, this enables auto-registration, which furthers enabled 4 severe exploits CVE-2024-39930 (CVSS score: 9.9) - Argument injection in the built-in SSH server CVE-2024-39931 (CVSS score: 9.9) - Deletion of internal files CVE-2024-39932 (CVSS score: 9.9) - Argument injection during changes preview CVE-2024-39933 (CVSS score: 7.7) - Argument injection when tagging new releases The fix You probably want to read the changelog at https://github.com/gogs/gogs/blob/main/CHANGELOG.md and update your configuration file accordingly. That is, renaming your [service] section to [auth] and reviewing your settings there while you are at it. Once this is done, check user accounts on your Gogs servers. If any new accounts registered, you will need to audit the underlying server looking for traces of further modifications, like unidentified processes running, e.g. crypto miners, access to further SSH keys, and the like. The reminder RTFM is not just for initial install : it is also for release notes. Each and every one of those.
• Tip of the day: using Homebrew to get PHP Pear extensions behind a proxy by Frederic Marand (2023/06/01 12:15)

  Tip of the day: using Homebrew to get PHP Pear extensions behind a proxy Frederic Marand Thu, 2023-06-01 14:15 PHP php pear pecl Homebrew macos Most of the time, installing tools using Homebrew works flawlessly, including PHP these days. However, having to work in a client environment requiring a proxy, the PHP 8.1 post-install failed when updating Pear/Pecl channels, although the usual http_proxy and https_proxy were set and worked normally, including for the other Homebrew tasks. What could be going on ? Turns out, the culprit is pear, which does not use those standard environment variables, but needs its own configuration, which is documented on https://pear.php.net/manual/en/guide.users.commandline.config.php The key is to simply add that config from the Pear CLI: pear config-set http_proxy http://(proxy IP):(proxy port) After that, pear update-channels works.. .. and so do brew install php@8.1, or just brew postinstall php@8.1 if you got tired of waiting for a timeout in brew install php@8.1 and killed it with ^C. That's all it takes!
• The end of function execution in Go code by Frederic Marand (2023/05/29 19:24)

  The end of function execution in Go code Frederic Marand Mon, 2023-05-29 21:24 Google Go = Golang DevoxxFR Every Go function needs to end at some point, even main and test functions. But the way the end impacts how we can work after they finish. This presentation created for DevoxxFR 2023 describes the available mechanisms.
• Tip of the day: validating a Jenkinsfile from the CLI with HTTPie by Frederic Marand (2023/05/19 12:56)

  Tip of the day: validating a Jenkinsfile from the CLI with HTTPie Frederic Marand Fri, 2023-05-19 14:56 Computing devops jenkins An easily missed feature in Jenkins is the bundled linter for Jenkinsfiles. While there are many examples about how to use it with cURL, I could not find any using HTTPie, which I find much more convenient in general than cURL. So, after some fumbling due to the little documented expectations of the validator, here is the solution showing how to validate a Jenkinsfile from the CLI: http --form                                         \     -a $USER:$PASS                                 \     -pb                                            \     POST                                           \     $JENKINS_URL/pipeline-model-converter/validate \     jenkinsfile=@$JENKINSFILE Let's see what these arguments mean: --form specifies use of the application/x-www-form-urlencoded MIME type, as expected by the validator -a $USER:$PASS provides basic authentication credentials. If you do not want to include the password, just use $USER: and HTTPie will request the password on the CLI. This assumes these two variables contain your Jenkins username and password -pb asks HTTPie to only print the response body $JENKINS_URL is the absolute URL to the Jenkins root $JENKINSFILE is the path to the Jenkinsfile to validate. May be relative or absolute That's it. Note that, as usual with HTTPie, the ordering is strict: http the command itself The options, like -a and --form The method, in this case POST. HTTPie uses GET by default The target URL The so-called "fields", which translate to the request body. In this case, the jenkinsfile=@$JENKINSFILE requests HTTPie to load the contents of the file designated by $JENKINSFILE and load that content as the value of the jenkinsfile HTML form field Hopefully, you will receive a result looking like this: Jenkinsfile successfully validated. More details in the HTTPie forms documentation.