šŸ‡§šŸ‡ŖBelgium @xaa

Brussels
Account created on 13 December 2008, over 15 years ago
#

Recent comments

šŸ‡§šŸ‡ŖBelgium xaa Brussels
šŸ‡§šŸ‡ŖBelgium xaa Brussels

Thank you, @nofue. What I wanted to highlight from my previous message is that the document does not mention the temporary folder. It could be helpful for everyone to include basic guidance, such as recommending ../tmp over sites/default/files/tmp for security (as ../tmp is outside the webroot), and emphasizing the importance of setting correct permissions.

šŸ‡§šŸ‡ŖBelgium xaa Brussels

Hi, there is no mention of the tmp/ folder in this documentation. Is it an oversight or by choice ?
I am looking for clear/official/bestpractice guidelines on how config the temporary folder (chmod and location outside advise). Thank you

šŸ‡§šŸ‡ŖBelgium xaa Brussels

Fix mistake in requirements + fix typo.

šŸ‡§šŸ‡ŖBelgium xaa Brussels

Thank you for your feedbacks. @apaderno I also agree that this structure isn't currently mandatory in Drupal. But contrib/ and custom/ structure put new user on the right track. A major benefit is that users can then easily gitignore themes/contrib. Better explanation in this ticket: https://www.drupal.org/project/drupal/issues/3082958#comment-15453508 āœØ Add gitignore(s) to Composer-ready project templates Needs work

Alternatively, we could explain at the beginning of the page that using the custom/ folder is recommended by the community but not a Drupal requirement. This way, the "below" examples wouldn't mention it to stay generic.

--
Note: If we adjust the directory structure in the code blocks, the Drupal and Drush commands need to be adjusted as well to reflect the new destination (--path themes/custom and --destination=themes/custom).). For drupal generate-theme, it seems the custom/ folder needs to be created first.

šŸ‡§šŸ‡ŖBelgium xaa Brussels

Should we mention the themes contrib/ and custom/ level as best practice?

themes/
ā””ā”€ā”€ contrib/
     | fluffiness/
     ā”œā”€ā”€ fluffiness.info.yml
     ā””ā”€ā”€ fluffiness.libraries.yml

and
 

themes/
ā””ā”€ā”€  custom/ 
       |my_custom_theme/
       ā”œā”€ā”€ my_custom_theme.info.yml
       ā””ā”€ā”€ my_custom_theme.libraries.yml
šŸ‡§šŸ‡ŖBelgium xaa Brussels

Complete page reformat (and minor but helpful info for new user added. Feel free to revert if you spot too much issues with this update. 
I have also added the Tag "Bootstrap 5" but I am wondering if a new Tag "Bootstrap 4/5" won't be better ?

šŸ‡§šŸ‡ŖBelgium xaa Brussels

I confirm #3 and #4. (5paceless has been fixed in 5.5.7 and 5.1.6).

šŸ‡§šŸ‡ŖBelgium xaa Brussels

same issue here (not using ddev).
2.1.2 works fine as well.

šŸ‡§šŸ‡ŖBelgium xaa Brussels

in my local I've fixed the issue by recompiling theme (in web/profiles & web/themes/custom). But the issue stills occurs after deployment.

In my droopler custom theme, I saw some calls from web/profiles/contrib/droopler/custom/themes/droopler_theme/js files.
The .gitignore contains !/web/profiles/custom but there is nothing there.

As a quick workaround I've added a line !/web/profiles/contrib/droopler to include the web/profiles/contrib/droopler files in git then deploy is ok

Hope it helps

šŸ‡§šŸ‡ŖBelgium xaa Brussels

same issue here (droopler 3.2.0)

šŸ‡§šŸ‡ŖBelgium xaa Brussels

patch from #20 working here. thanks

šŸ‡§šŸ‡ŖBelgium xaa Brussels

Same here. no spam received since patch applied on 2 websites and the legit emails are still coming.

šŸ‡§šŸ‡ŖBelgium xaa Brussels

Thank you for your quick reaction Ewout! I'am also testing the patch (on a d9.5.9).

šŸ‡§šŸ‡ŖBelgium xaa Brussels

Patch #35 for 1.11 applied on d10.2.3. thank you.

šŸ‡§šŸ‡ŖBelgium xaa Brussels

I saw similar issue on a d10.2.0 (upgraded from 9.5.11) after adding URL alias (/admin/config/search/path/add). Patch #20 seems fixed the issue here.

trying to create alias:
- System path: /node
- URL alias: /

šŸ‡§šŸ‡ŖBelgium xaa Brussels

hi there, same issue here when scanning the custom theme (using 8.x-3.19, php 7.4).

šŸ‡§šŸ‡ŖBelgium xaa Brussels

hi, thank you generalredneck. It seems I also need patch in #10 after a d9.4.8 > d9.5.11 update, possible?

When trying to access a node the patch from #10 solves the error "InvalidArgumentException: Provided value is out of range. in Drupal\time_field\Time::assertInRange() (line 64 of modules/contrib/time_field/src/Time.php)". The node edit page was also broken (impossible to access/edit the node). Should I open a new ticket for this report ? (as it may need more attention and a higher priority level as the error fully broke the access to the /node/xx/edit page).

šŸ‡§šŸ‡ŖBelgium xaa Brussels

Awesome, thank you! Patch is working on 10.1.x using php 8.1

šŸ‡§šŸ‡ŖBelgium xaa Brussels

hi, #96 doesn't seems apply on 10.1.x

šŸ‡§šŸ‡ŖBelgium xaa Brussels

I confirm patch is working. Thank you. I had same error after update from 2.1.2 to 2.2.0.

I elevate the ticket priority as this issue make some backend pages fully not working (eg /admin/structure/types/manage/your_content_type).

šŸ‡§šŸ‡ŖBelgium xaa Brussels

yeah thanks !

šŸ‡§šŸ‡ŖBelgium xaa Brussels

Thank you for the patch. It's working but on desktop the toolbar menu is then always closed. On desktop the toolbar should stay opened if user has opened it, isnt' it?

šŸ‡§šŸ‡ŖBelgium xaa Brussels

hi m42. I am interested by the Conversion API integration for D8+. Could you share more info about this ? Thank you

Production build 0.69.0 2024