There doesn't seem to be a GitLab flavor extension for CommonMark
But there is. and has been at least since Jan 13, 2022. The Markdown module supports CommonMark 1.6.7, whose changelog is dated Jan 13, 2022. Markdown also supports PHP Markdown Extra directly and through Parsedown Extra. PHP Markdown Extra has a more extensive list of supported extensions than CommonMark GFM.
I have at least temporarily given up on Markdown, it blocks the Add text format button with an error. I won't go into details, just so you know my motivation.
Markdown Easy installs CommonMark 2.5.3, so it gets CommonMark GFM. I've tested the Extensions listed on then GitHub-Flavored Markdown. Autolinks. Disallowed Raw HTML, Strikethrough and Tables work. Tables does not do cell alignment, but that may be my inability to get Limit allowed HTML tags and correct faulty HTML to let the align=foo attribute pass. (Any hints?) The Task List extension partially works, it gobbles the [x] and [ ] up.
So I believe that unless someone wants to add support for PHP Markdown Extra or Parsedown Extra, this ticket can be closed. But maybe somebody who is familiar with the Markdown Easy and CommonMark code could have a look at the the two defects I found. Tell me if you want me to open tickets for them.
I stumbled over the missing command that made Drush work. drush site:install
and all the commands are available. Turns out I was too focused on migration, which does not work for Drupal beyond 7.
What worked was to build a fresh Composer and Drush installation and run site:install which wants to knock down my existing database, but what is mysqldump for? Just reloaded the dump and I had a running Drupal 9 with a working composer/drush. Following How to upgrade from Drupal 9 to Drupal 10 → did the rest of the work.
Since there does not seem a way to get drush to run config export/import, I decided to bite the bullet and implement a PHP script to unserialize, edit and serialize the rows in the config table that contain the permissions Upgrade Status complains about. I did not include the database access to select and update the data. I intended to use it only on my test VM and in production. Upgrade Status is content now, so I can proceed with the migration.
The code "knows" which permissions must be removed for which database and which user roles, so I just have to edit it to include the output of the select command and run it to get the data to past into the update command. Very clumsy, I admit, but it did the work.
I'd still like to have a drush with full capabilities, since I ran into the same problem on my Drupal 10 VM where I intend to migrate the Drupal 9 data to Drupal 10, like I did from 7 to 9. My first VM has so many snapshots now that I'm losing track of which snapshot to fall back if something goes wrong. I was already using to snapshot chains at one time...
First time I read that drush requires a Docker container. No, I'm running a VM. I tried dabbling with Docker some years ago and wasn't convinced it gained anything but unnecessary complexity. Then biggest problem though was that the images I found for running small services like DHCP, DNS, or NTP were never updated, leaving gaping security gaps. So I gave up on Docker.
run drush version
It should read > 10 (11.6.0 here)
$ drush version
Drush version : 11.6.0
Then you should be able to run drush config:export without changing any settings.
Sorry, but no. :-(
Depending on your access level at the command line, you may execute a different version of drush.
I have only one instance of drush, and one symlink in /usr/local/bin:
$ ls -l $(which drush)
lrwxrwxrwx 1 lupe lupe 57 Nov 19 21:23 /usr/local/bin/drush -> /var/www.lupe/drupal-recommended-project/vendor/bin/drush
$ /var/www.lupe/drupal-recommended-project/vendor/bin/drush version
Drush version : 11.6.0
I also encountered a access rights problem on OS level. drush had an issue accessing a hidden subdirectory because of either missing access rights or wrong owner:user settings.
Very unlikely, I work on composer stuff only with my personal user.
My current server provides PHP 7.x on system level and PHP 8.x on user level, which causes issues when running scripts as root (which is bad behaviour, but …).
Pretty awkward and confusing. I use update-alternatives when I switch PHP versions, so there is only /usr/bin/php which currently points to php8.1.
Thanks for all the input, but still no dice. :-( Something seems to be missing that is required for drush to operate, for example I found no way to enter database access data or an URI pointing to a Drupal instance. Or something that enables the config:import/export commands.
You can read the the "Configuration management" → section.
The examples in the sections "Managing your site's configuration" and "Workflow using Drush" don't work for me:
drush cget system.site uuid
Command cget was not found. Drush was unable to query the database. As a result, many commands are unavailable. Re-run your command with --debug to see relevant log messages.
drush config:export
Command config:export was not found.
I'm asking how to set up the drush environment for a reason. :-(
Thaks, but I did that. And messed it up a long time ago, but noticed only now when I couldn't go forth or back. Since I used the tarballs until Drupal 7, I triewd to uipgrade to Drupal 8 from the tarball and failed. Then, I set up a VM with the same Debian the productive server has and installed composer. I had a few tries to get that to work because the instrcutions aren't exactly clear for someone who has no experience with it, and that may be the cause of the present problems. I don't intend a post mortem, though.
If I find I need explanations, I'll contact you. OK?
It looks like your website has been been fubared by a number of CLI-commands that I don't comprehend.
Me neither :-(
If you have a backup, try to roll back to the point when you had a working Drupal 9.5.11 site, and I'll try to provide guidance about how to progress with upgrading to version 10.1.6 from there.
I have plenty of snapshots, but, alas, the problem reaches too far back to a point when it's easier to start afresh. So there is no way to fix the composer, I'll rather invest the work to a clean one.
Thanks for your effort, sorry it was only good to convince me that I need to start over.
I see that for Upgrade Status, you've followed the instructions under the heading. "Installation on sites not using composer".
Those are:
$ composer create-project 'drupal/recommended-project:~9.5' d10readiness
$ cd d10readiness
$ composer show drupal/core | grep versions
$ composer require --dev drupal/core-dev:[copy version above]
$ composer require drupal/upgrade_status
The commands for "Install Upgrade Status on your existing Drupal site.":
$ composer show drupal/core | grep versions
$ composer require --dev drupal/core-dev:[copy version above] --update-with-all-dependencies
$ composer require drupal/upgrade_status
What I did was:
lupe@drupal-development:/var/www.lupe/drupal-recommended-project$ composer show drupal/core | grep versions
versions : * 9.5.11
lupe@drupal-development:/var/www.lupe/drupal-recommended-project$ composer require --dev drupal/core-dev:9.5.11 --update-with-all-dependencies
./composer.json has been updated
Running composer update drupal/core-dev --with-all-dependencies
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires drupal/core-dev 9.5.11 -> satisfiable by drupal/core-dev[9.5.11].
- drupal/core-dev 9.5.11 requires symfony/dom-crawler ^4.4 !=4.4.5 -> found symfony/dom-crawler[v4.4.0, ..., v4.4.45] but these were not loaded, likely because it conflicts with another require.
Installation failed, reverting ./composer.json and ./composer.lock to their original content.
I did not run composer require drupal/upgrade_status
because the preceding require command failed. Hence, I can't access the Upgrade Status module at all.
This is the state after the failed <code>composer require --dev drupal/core-dev:9.5.11 --update-with-all-dependencies</code>.
{
"name": "drupal/recommended-project",
"description": "Project template for Drupal 9 projects with a relocated document root",
"type": "project",
"license": "GPL-2.0-or-later",
"homepage": "https://www.drupal.org/project/drupal",
"support": {
"docs": "https://www.drupal.org/docs/user_guide/en/index.html",
"chat": "https://www.drupal.org/node/314178"
},
"repositories": [
{
"type": "composer",
"url": "https://packages.drupal.org/8"
}
],
"require": {
"composer/installers": "^1.9",
"drupal/auditfiles": "^3.0",
"drupal/bartik": "^1.0",
"drupal/codefilter": "1.x-dev@dev",
"drupal/convert_bundles": "^2.0@beta",
"drupal/core-composer-scaffold": "9.5.11",
"drupal/core-project-message": "9.5.11",
"drupal/core-recommended": "9.5.11",
"drupal/editor_md": "^4.0",
"drupal/file_upload_directory_change": "^2.0@beta",
"drupal/filefield_paths": "^1.0@beta",
"drupal/markdown": "^3.0",
"drupal/pdf_api": "^2.4",
"drupal/printable": "^3.0",
"drupal/security_review": "^2.0",
"drupal/seven": "^1.0",
"drupal/tac_lite": "^1.7",
"drupal/taxonomy_menu": "^3.6",
"drupal/taxonomy_menu_ui": "^3.0",
"drupal/typogrify": "^1.2",
"drupal/xbbcode": "^5.0",
"league/commonmark": "^2.4",
"mpdf/mpdf": "v8.2.0"
},
"conflict": {
"drupal/drupal": "*"
},
"minimum-stability": "stable",
"prefer-stable": true,
"config": {
"sort-packages": true,
"allow-plugins": {
"composer/installers": true,
"drupal/core-composer-scaffold": true,
"drupal/core-project-message": true
}
},
"extra": {
"drupal-scaffold": {
"locations": {
"web-root": "web/"
}
},
"installer-paths": {
"web/core": [
"type:drupal-core"
],
"web/libraries/{$name}": [
"type:drupal-library"
],
"web/modules/contrib/{$name}": [
"type:drupal-module"
],
"web/profiles/contrib/{$name}": [
"type:drupal-profile"
],
"web/themes/contrib/{$name}": [
"type:drupal-theme"
],
"drush/Commands/contrib/{$name}": [
"type:drupal-drush"
],
"web/modules/custom/{$name}": [
"type:drupal-custom-module"
],
"web/profiles/custom/{$name}": [
"type:drupal-custom-profile"
],
"web/themes/custom/{$name}": [
"type:drupal-custom-theme"
]
},
"drupal-core-project-message": {
"include-keys": [
"homepage",
"support"
],
"post-create-project-cmd-message": [
"<bg=blue;fg=white> </>",
"<bg=blue;fg=white> Congratulations, you’ve installed the Drupal codebase </>",
"<bg=blue;fg=white> from the drupal/recommended-project template! </>",
"<bg=blue;fg=white> </>",
"",
"<bg=yellow;fg=black>Next steps</>:",
" * Install the site: https://www.drupal.org/docs/8/install",
" * Read the user guide: https://www.drupal.org/docs/user_guide/en/index.html",
" * Get support: https://www.drupal.org/support",
" * Get involved with the Drupal community:",
" https://www.drupal.org/getting-involved",
" * Remove the plugin that prints this message:",
" composer remove drupal/core-project-message"
]
}
}
}
I've taken the liberty of moving this question there.
Thanks! I did not think of looking for a composer forum.
When asking for help with composer popblems, please Share your composer.json file for Composer questions and some other details about your configuration.
I see no way to attach a file to a thread. I'll put the composer.json in a separate message to avoid making this one unreadable. Please list what files would also be helpful.
As for xbbcode 5.0 - I tried with that and it did not work, either. Here goes, with PHP 8. and xbbcode 5.0:
lupe@drupal-development:/var/www.lupe/drupal-recommended-project$ php -v
PHP 8.1.17 (cli) (built: Mar 16 2023 14:37:38) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.17, Copyright (c) Zend Technologies
with Zend OPcache v8.1.17, Copyright (c), by Zend Technologies
lupe@drupal-development:/var/www.lupe/drupal-recommended-project$ composer require 'drupal/xbbcode:^5.0'
./composer.json has been updated
Running composer update drupal/xbbcode
Loading composer repositories with package information
Updating dependencies
Nothing to modify in lock file
Installing dependencies from lock file (including require-dev)
Nothing to install, update or remove
Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.
Package symfony/debug is abandoned, you should avoid using it. Use symfony/error-handler instead.
Generating autoload files
49 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
That's not a problem. On to the Upgrade Status module, as described on the module page:
lupe@drupal-development:/var/www.lupe/drupal-recommended-project$ composer show drupal/core | grep versions
versions : * 9.5.11
lupe@drupal-development:/var/www.lupe/drupal-recommended-project$ composer require --dev drupal/core-dev:9.5.11 --update-with-all-dependencies
./composer.json has been updated
Running composer update drupal/core-dev --with-all-dependencies
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires drupal/core-dev 9.5.11 -> satisfiable by drupal/core-dev[9.5.11].
- drupal/core-dev 9.5.11 requires symfony/dom-crawler ^4.4 !=4.4.5 -> found symfony/dom-crawler[v4.4.0, ..., v4.4.45] but these were not loaded, likely because it conflicts with another require.
The symphony/doc-crawler is not in the Drupal Modules project, so I have no "require" line. And I don't know how to update that module:
lupe@drupal-development:/var/www.lupe/drupal-recommended-project$ composer require 'vendor/symfony/dom-crawler:^4.4'
./composer.json has been updated
Installation failed, reverting ./composer.json and ./composer.lock to their original content.
In RootPackageLoader.php line 162:
require.vendor/symfony/dom-crawler is invalid, it should have a vendor name, a forward slash, and a package name. The vendor and package name can be words separated by -, . or _. The complete name should match "^[a-z0-9]([_.-]
?[a-z0-9]+)*/[a-z0-9](([_.]?|-{0,2})[a-z0-9]+)*$".
require [--dev] [--dry-run] [--prefer-source] [--prefer-dist] [--prefer-install PREFER-INSTALL] [--fixed] [--no-suggest] [--no-progress] [--no-update] [--no-install] [--update-no-dev] [-w|--update-with-dependencies] [-W|--update-with-all-dependencies] [--with-dependencies] [--with-all-dependencies] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [--sort-packages] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--apcu-autoloader-prefix APCU-AUTOLOADER-PREFIX] [--] [<packages>...]
lupe@drupal-development:/var/www.lupe/drupal-recommended-project$ composer require 'vendor/symfony/dom-crawler'
In PackageDiscoveryTrait.php line 375:
Could not find a matching version of package vendor/symfony/dom-crawler. Check the package spelling, your version constraint and that the package is available in a stability which matches your minimum-stability (stable).
require [--dev] [--dry-run] [--prefer-source] [--prefer-dist] [--prefer-install PREFER-INSTALL] [--fixed] [--no-suggest] [--no-progress] [--no-update] [--no-install] [--update-no-dev] [-w|--update-with-dependencies] [-W|--update-with-all-dependencies] [--with-dependencies] [--with-all-dependencies] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [--sort-packages] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--apcu-autoloader-prefix APCU-AUTOLOADER-PREFIX] [--] [<packages>...]
Please advise.
<p><code class="language-php">$ composer require 'drupal/pdf_api:^2.3'<br />
./composer.json has been updated<br />
Running composer update drupal/pdf_api<br />
Loading composer repositories with package information<br />
Updating dependencies<br />
Nothing to modify in lock file<br />
Installing dependencies from lock file (including require-dev)<br />
Nothing to install, update or remove<br />
Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.<br />
Package symfony/debug is abandoned, you should avoid using it. Use symfony/error-handler instead.<br />
Generating autoload files<br />
48 packages you are using are looking for funding.<br />
Use the `composer fund` command to find out more!<br />
$ cat web/modules/contrib/pdf_api/pdf_api.info.yml<br />
name: PDF API<br />
type: module<br />
description: 'Provides an API for generating PDFs.'<br />
package: PDF<br />
core_version_requirement: ^8.8 || ^9 || ^10<br />
<br />
# Information added by Drupal.org packaging script on 2023-03-11<br />
version: '2.3.0'<br />
project: 'pdf_api'<br />
datestamp: 1678574176</code></p>
When I run composer require 'drupal/pdf_api:^2.3.1'
, I get a new error:
- drupal/pdf_api 2.3.1 requires mpdf/mpdf ^8.1.6 -> found mpdf/mpdf[v8.1.6] but the package is fixed to v8.1.2 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for th
e update command.
This is fixable by including mpdf/mpdf in the command like this: composer require 'drupal/pdf_api:^2.3.1' 'mpdf/mpdf'.
This installs both updates without a complaint. I'll not try not to understand what happened here and just close the ticket.
Thanks for you help!
I'm sorry, you may not have noticed that I'm using the same versions of Drupal, PHP, and pdf_api as you have. But something prevents this from working on my composer installation. And not knowing my way around the composer, I have no idea what to do to correct this.
I probably need some very basic help. Just telling me that this works for you does not help me find the cause of my problem. :-(