Si si! Se pueden hacer propuestas y no ser ponente de las mismas. Mi pregunta era por tenerlo claro y reflejarlo en la descripción.
Gracias!
@ygoex ++++++++++++
Gracias! Lo apunto en la descripción de la issue.
Buenas @cbccharlie,
Serías tu el ponente de esta propuesta? o es una idea por si alguien se anima?
Gracias!
Buenas! @Alexjluna, serías tu el ponente de esta propuesta?
Un saludo!
+1
Añado las slides de la charla.
Closing since the request is out of scope of this project.
Hello @adaragao,
Unfortunately the scope of this module is just to replace the language name by the langcode on the core Language Switcher block.
Any customization on the styling of how the block is displayed should be done by other module or custom CSS on your theme. Not on this module.
I did a quick search and the closest issue/project I've found related with your request by far is https://www.drupal.org/project/drupal/issues/3127588 →
All the best.
jlbellido → created an issue.
Asignados los creditos a las personas que han estado presentes en la llamada.
Tras hablar con @alemadlei hemos acordado fecha y hora del evento. He actualizado la issue con los datos del mismo.
Gracias @alemadlei por el ofrecimiento!
Por mi parte perfecto que des tu esta charla! Hablamos por slack para cuadrar fecha y hora.
Gracias @idiaz.roncero, viendo tu comentario veo que estas a tope y no te cuadra mucho. De cualquier manera, como el tema es bastante amplio, puedes proponer otra charla con otro enfoque sobre lo que quieras.
jlbellido → created an issue.
Ok, I had a second look and I was mistaken.
#2 Is correct, because it is using hook_field_widget_single_element_form_alter which is the recommended replacement for hook_field_widget_complete_form_alter().
#4 Uses hook_field_widget_complete_form_alter() instead but it is not needed for this context.
In any case, I think it would be good to have a MR with the #2 approach. In that way it is easier for maintainers to merge it.
Thanks both!
Hello,
I've checked the patch from #2 but unfortunately it is not complete and didn't work for me.
I've also tested the MR from #4 and it did work. Now the current domain is applied as default value for taxonomies in my case.
Finally, I'm adding some additional context information to the ticket description.
Añado el cartel promocional
Planeada para el Miercoles 6 de Marzo - 17:00h
+1
+1
A mi me encantaría esta charla, cuando trabajas con PHPStan hay varias cosas que no son tan evidentes como cuando usar Stub files o estrategias para ir mejorando proyectos poco a poco con PHPStan.
Sólo queda una persona por darle karma.
Fijada para la primera quedada.
After [#] has been merged, now we can see we are passing the PHPStan check within !32 if we compare it with the last run on the main project (https://git.drupalcode.org/project/examples/-/pipelines/85372)
Therefore I'd say this is fully ready to be reviewed by someone else.
Thanks!
I've just seen we have a different .eslintrc configuration if we compare it with the one from Drupal core. Would we need to align ours with the new version from core? I'm not experienced on this kind of tasks but it seems to me than most of the errors we see on the reporting might be caused by this misalignment?
I've sent an initial MR fixing the errors found by Eslint on the REST module.
I'm sending an initial MR fixing the issues found.
While I worked on
📌
Pass Eslint validations: Testing example
Needs review
I noticed that I got different errors locally than the ones reported by eslint when it is run by Gitlab CI.
After checking how it is run by default on Gitlab, I'm updating the instructions about how to run the eslint locally because it diffiers from what it is written at
https://www.drupal.org/docs/develop/standards/javascript-coding-standard... →
and it could lead to confusions on the different child issues.
I'm sending a MR fixing the detected issues by eslint for the Testing example.
I've created an initial MR solving the errors reported by Eslint on the Tour module. I think it is ready now.
I've checked in deep the error from #5 but I think Stub files is not the right way because they are meant for other kind of scenarios according to (https://phpstan.org/user-guide/stub-files). Therefore I don't see other way to get rid of it than ignoring it via php-baseline.neon
I've added a new commit with this approach.
Now we are passing the PHPStan checks for Level 1:
$ php ../vendor/bin/phpstan analyze --configuration modules/contrib/examples/phpstan.neon modules/contrib/examples
242/242 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%
[OK] No errors
I think this is now ready to be reviewed.
Hello,
I've created an initial MR fixing most of the errors reported. It still pending the following one:
------ ---------------------------------------------------------------------
Line modules/file_example/src/FileExampleSubmitHandlerHelper.php
------ ---------------------------------------------------------------------
460 Class Drupal\devel\DevelDumperInterface not found.
💡 Learn more at https://phpstan.org/user-guide/discovering-symbols
I don't really know if by using Stub files we can fix it since it is a conditional class not always present (depending is Devel is required or not).
I'm attaching the initial report with all the issues detected before fixing anything:
jlbellido → created an issue.
I've created 📌 [Meta] Pass Eslint validations Active as a follow up task to have the eslint validation checks passing.
We will need to create more tasks to fix other issues we have currently with the final goal of having everything in green.
jlbellido → created an issue.
jlbellido → created an issue.
jlbellido → created an issue.
jlbellido → created an issue.
jlbellido → created an issue.
jlbellido → created an issue.
jlbellido → created an issue.
jlbellido → created an issue.
jlbellido → created an issue.
jlbellido → created an issue.
jlbellido → created an issue.
jlbellido → created an issue.
jlbellido → created an issue.
jlbellido → created an issue.