🇨🇭Switzerland @mullzk

Tested on 10.1.5 as described in #35, MR resolves the issue
Tested on Drupal 9.5.11 as well, Redirect works as expected, CSS-& JS-Assets are generated as usual.

Hi
I tested #34 on my installation and it worked.

Drupal 10.1.5, Redirect 8.x-1.9, multilingual
=> Having redirect AND css/js-aggregation enabled leads to css/js-files no longer being loaded.
=> Using the issue-fork from juanjol fixes this (as does disabling css/js-aggregetion or disabling redirect).

Thanks a lot for your work. Hope this gets merged soon.

We are in the mentoring-contribution-workshop in DrupalCon Lille, and started to work on this issue.
Currently, we all get an error when starting up DrupalPod:

Notice: running 'composer update --lock' in ddev
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 == 11.9999999.9999999.9999999-dev -> satisfiable by drupal/core[11.x-dev].
    - drupal/core 11.x-dev requires symfony/console ^4.4 -> found symfony/console[v4.4.0-BETA1, ..., 4.4.x-dev] but these were not loaded, likely because it conflicts with another require.
  Problem 2
    - Root composer.json requires drupal/core-recommended == 11.9999999.9999999.9999999-dev -> satisfiable by drupal/core-recommended[11.x-dev].
    - drupal/core-recommended 11.x-dev requires drupal/core 9.2.x-dev -> satisfiable by drupal/core[9.2.x-dev] from composer repo (https://repo.packagist.org) but drupal/core[dev-3181647-add-autocomplete-attributes, 11.x-dev] from path repo (repos/drupal/core) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.
  Problem 3
    - Root composer.json requires drupal/core-dev == 11.9999999.9999999.9999999-dev -> satisfiable by drupal/core-dev[11.x-dev].
    - drupal/core-dev 11.x-dev requires behat/mink-browserkit-driver ^1.3 -> found behat/mink-browserkit-driver[v1.3.0, ..., 1.x-dev] but these were not loaded, likely because it conflicts with another require.

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
Failed to execute command composer update --lock: exit status 2
Failed to run exec_dir composer update --lock; error=exit status 1

real    0m13.019s
user    0m0.246s
sys     0m0.356s
gitpod /workspace/DrupalPod (main) $ 

Manually installing with ddev composer install worked, but then, drush was missing.
Manually installing with ddev composer require drush/drush worked, but then we get an error when installing the site:

gitpod /workspace/DrupalPod (main) $ ddev drush si --account-pass=admin
PHP Fatal error:  Class Drush\Commands\core_development\DevelopmentProjectCommands cannot extend final class Drush\Commands\core\CacheCommands in /var/www/html/drush/Commands/core_development/DevelopmentProjectCommands.php on line 0

Fatal error: Class Drush\Commands\core_development\DevelopmentProjectCommands cannot extend final class Drush\Commands\core\CacheCommands in /var/www/html/drush/Commands/core_development/DevelopmentProjectCommands.php on line 0
 [warning] Drush command terminated abnormally.
Failed to run drush si --account-pass=admin: exit status 1
gitpod /workspace/DrupalPod (main) $ 

Grevil → credited mullzk → .

Finally I managed to push some test for the de-obfuscation-process. Sorry for all my beginners-git-chaos.

Even if those test pass, I think lmoeni has an important point that the mechanism for obfuscating mail-addresses in the link-text should use the value of the "spamspan_at" and "spamspan_dot" settings. Just replacing . with dot and @ with at is a well known practice and can be deobfuscated by spambots without any javascript. But perhaps this should be discussed in another issue?

On my system, the MR above (#3375801) did not solve the issue.

the issue is in javascript.js, around line 43 - where the regex for Email-Adresses inside the anchor-element (not in the attributes, but in the link-text) is not accurate enough. The regex leads to invalid results if the email-adress contains dots, dashes, 'at' or 'dot'

mail@sub.domain.com becomes mail@sub.domaindotcom
mail@web-site.com becomes mailatweb-sitedotcom
first.name@notariatadvokatur.com becomes first.name@notariatadvokaturdotcom
anecdotal.story@example.com becomes anec.aldotstory@exampledotcom

If you have drush installed, sometimes the following commands can help on errors like these:

drush cr (clear all caches)
drush updb (perform any pendent database-updates, esp. after installing/removing modules)
drush pml (list modules)
drush pmu (uninstall modules)

Be sure, that every enabled module is present. In the beginning, I often got this error when I uninstalled a module in composer, but still relied on it in the system...

There are three different parts to consider: Content, Configuration, Code

Content: As you mentioned, content is managed by your users on the production site. You can sync it to your development site by syncing DB and Files. I do that with drush: drush sql-sync @prod @self && drush rsync @prod:%files @self:%files && drush rsync @prod:%files @self:%files. As we never want to over-write content from our users, we never use those commands for the opposite direction (we only pull from and never push to Production).

Code: It is a good practise never to manipulate code on the Production-system. All changes (to themes, modules, composer.json etc.) should happen on your Development system and then be pushed to prod. We do that with git (having all the content and all the composer-installed parts in .gitignore); if you prefer any way, this is also possible.

Config: This is the part where it gets messy. Config can be changed both on Production and on the Development site. This can get especially hairy if your users have the necessary permissions to change config items.

• Config is part of the Database and therefore can be synced by drush sql:sync
• Config can also be synced to the filesystem (/admin/config/development/configuration and drush cst|cex|cim) and therefore be tracked, versioned and deployed.
• Content not in Sync with config can lead to fatal php errors.
• Config not in Sync with Code can lead to fatal php errors.

Our workflow:

• We pull the config as part of our content-pull-script from Production to Development.
• On our Development site, we export the config from database to filesystem with drush cex
• We push (and version) the filesystem-config from Development through git-repo to Production
• On our Production site, we import the config from filesystem into database.

I am very sorry about the multiple issue forks above. This is the first time I tried to contribute, and then I pushed to the wrong branch and then it went all downhill from there. If anybody has the rights and the wits to clean up all of my stuff, I sure would be grateful.
[so embarrassing...]

While I wrote my issue, lmoeni wrote an issue about the same bug. I posted my information in her issue and close this issue here...
https://www.drupal.org/project/spamspan/issues/3376462 🐛 Email addresses with multiple dots cause problem in link content Closed: duplicate

The content of the link not only is wrong when there is more than one dot in the domain-part, but also if the domain contains a dash:

## Input in CKEditor (no matter if ckeditor4 or ckeditor5, no matter if full_html or basic_html)
Source: Test-mail-link: test@example-site.com

## Expected Behaviour: Output in SpamSpan 8.x-1.3
Source: Test-mail-link: test [at] example-site [punkt] com
After Javascript: Test-mail-link: test@example-site.com

## Unexpected Behaviour: Output in SpamSpan 3.1.3
Source: Test-mail-link: test [at] example-site [punkt] com (testatexample-sitedotcom)
After Javascript: Test-mail-link: testatexample-sitedotcom

The issue does not occur with dashes or other special-characters in the user-part of the email-adress.
The issue does not occur on email-addresses without a-mailto-links.

Proposed resolution

As far as I understand, there is a mismatch in the Pattern-Matching in SpamspanTrait.php#filterTagContents (which accepts dashes in Domains) and the much more simplified version in spamspan.js at line 43, which only matches \w ([a-zA-Z0-9_], but no -)

The easiest fix (which I already use on my system) is to change the regex in spamspan.js, line 43, to something like
const emailPattern = /\b\w+at(-|\.|\w)+dot\w+\b/g;

Best improvement would probably use the same patterns as in SpamspanInterface::PATTERN_EMAIL_BARE

mullzk → created an issue.

I can confirm that the fix in #12 | #13 fixes my problem in #10. I could update to media_directories 2.0.4 and the entity- and embed-modules remained installed.
Thank you very much

Hi there
Under what version of composer did you build/test this?
On my installation, the update from 2.0.2 to 2.0.3 breaks my Drupal-Installation, as it removes drupal/embed, drupal/entity_browser and drupal/entity_embed from composer.

I use composer 2.3.2. If I
composer require drupal/media_directories=2.0.2
then I get

$ composer show drupal/media_directories
name     : drupal/media_directories
...
versions : * 2.0.2
...
requires
drupal/core >=8.8.3
drupal/embed >=1.3
drupal/entity_browser >=2
drupal/entity_embed >=1

requires (dev)
drupal/embed ^1.3
drupal/entity_browser *
drupal/entity_embed *
drupal/media_directories_ui *

If I composer require drupal/media_directories=2.0.3
then composer does

Lock file operations: 0 installs, 1 update, 3 removals
  - Removing drupal/embed (1.6.0)
  - Removing drupal/entity_browser (2.9.0)
  - Removing drupal/entity_embed (1.3.0)
  - Upgrading drupal/media_directories (2.0.2 => 2.0.3)

and I get

$ composer show drupal/media_directories
name     : drupal/media_directories
..
versions : * 2.0.3
...
requires
drupal/core ^8.8.3 || ^9

requires (dev)
drupal/embed ^1.3
drupal/entity_browser *
drupal/entity_embed *
drupal/media_directories_ui *

I suspect, that the ">=8.8.3 - 9"-syntax breaks my composer-version. As far as I understand Composer Doc, it should be "8.8.3 - 9", ">=8.8.3 <=10.0.0". Or of course with semver "^8.8.3 || ^9".