I cannot create an interdiff, but I based my patch on #53-1.x.
In D10, the hook hook_field_widget_WIDGET_TYPE_form_alter does not exist anymore and is replaced by hook_field_widget_single_element_WIDGET_TYPE_form_alter, so the hook gnode_field_widget_media_library_widget_form_alter must be gnode_field_widget_single_element_media_library_widget_form_alter
Change record: https://www.drupal.org/node/3180429 →
dimitriskr → changed the visibility of the branch 3539366-10.5.x-tx-isolation-mysql to hidden.
dimitriskr → changed the visibility of the branch 3539366-11.x-tx-isolation-mysql to hidden.
Class parameters to property promotion (split into multiple lines was added by me) suggested by smustgrave to be in-scope here
Is there a general plan in core of switching classes to use property promotion/multi-line? I can switch all of these here to it, but I don't want to interfere if there's something existing already.
That's true, checked locally too.
So if the docs exist and it's wrong, phpcs complains. If it doesn't exist, all is well! I can clean this up
Also, we're not even discussing adding @inheritDoc, right? It's about completely removing the docblocks
@dcam I agree on the policy suggestion, but phpcs complains on the pipeline, that's why I had to add them. We need to change our coding standards too.
I suggest moving it back to NR unless this policy is going to be enforced really soon.
dimitriskr → created an issue.
update on versions:
10.6 is LTS and is EOL in 11 months (we have this already available)
10.11 - LTS - EOL 2y6m
11.4 - LTS - EOL 3y10m
11.8 - LTS - EOL 2y10m
source: https://endoflife.date/mariadb
dimitriskr → created an issue.
dimitriskr → changed the visibility of the branch dev to hidden.
vensires → credited dimitriskr → .
Is it a better idea to move this functionality into a submodule?
@avpaderno I now understand.
The rules/policy/guidelines (term TBC as I see) are not favourable for my situation.
But I shouldn't need to break an issue into multiple so I can just have more commits on a project's to-be-reviewed branch, especially for a module that's already feature-complete, but abandoned until I started (co-)maintaining it. I think we can move this review into "postponed" status until I either create more commits or the docs change. I will also write in
🌱
More flexible language for git vetted status for co-maintainers of existing projects
Active
and offer my POV
vensires → credited dimitriskr → .
In links in #2 I don't see any rule applying for the amount of commits done by the user, rather than the commits done show the user understands and uses the Drupal coding standards and the API correctly, which, in my opinion, is being displayed.
Is there another page/policy that applies here, which is not shared?
Most of my work, upon receiving maintainership, was done in this issue 📌 paragonie/easyrsa project was abandoned long time ago Needs work at this MR which includes a lot of commits, where they have been squashed into the project's branch. Does that qualify?
Hi @avpaderno
Yes. Branch 2.x has my commits where I added Gitlab CI tests and fixed whatever was reported, updated README.md and replaced the usage of an unsupported library with a better one. All but README.md updates are included in the module's 2.0.0-beta1 release
dimitriskr → created an issue.
dimitriskr → created an issue.
vensires → credited dimitriskr → .
I got a similar error on my project. I'm trying to find clean reproducible steps. For now, I got it when I tried to render a message entity that had an entity reference field for a view and I used a token [message:field_view_ref:entity:label] in the message's text and rendered it programmatically
Error: Object of class Drupal\views\Entity\View could not be converted to string in Drupal\Component\Render\HtmlEscapedText->__construct() (line 31 of core/lib/Drupal/Component/Render/HtmlEscapedText.php).
$view_builder = \Drupal::entityTypeManager()->getViewBuilder('message');
$pre_render = $view_builder->view($message_entity, 'default');
vensires → credited dimitriskr → .
I'm also getting a similar error, but on a different occasion, for example when a (malicious) request goes to /contact/Perú
I'll try to reproduce it on a clean install and upload a failing test
Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[HY000]: General error: 1267 Illegal mix of collations (ascii_general_ci,IMPLICIT) and (utf8mb4_general_ci,COERCIBLE) for operation '=': SELECT "name", "data" FROM "config" WHERE "collection" = :collection AND "name" IN ( :names__0 ); Array ( [:collection] => [:names__0] => contact.form.Perú ) in Drupal\Core\Config\DatabaseStorage->readMultiple() (line 111 of web/core/lib/Drupal/Core/Config/DatabaseStorage.php).
vensires → credited dimitriskr → .
@anybody there's some work going on in 3160987
I agree creating a formatters/tabs.css to fix this on vertical tabs too. You can use the branch I'm working on, no need to have multiple branches and MRs
As for interfering with other themes, only testing can prove that. I see in tag, data-once="" has a claroDetails, so we could limit it like this. Again, I am not familiar with front-end stuff in Drupal, so I'm just throwing random ideas :D Adding a related issue I saw about this
I've identified the issue (or hacked the module into making this work?) I have no good knowledge of CSS but the point is something is missing in the module's CSS files. I compared it with claro's form.css component and copy-pasted the CSS. I guess it needs tests on several other admin themes (gin etc) but I believe we now know what's going on.
Work is done on MR 108
I'm also uploading screenshots of before-after on my project
dimitriskr → made their first commit to this issue’s fork.
dimitriskr → changed the visibility of the branch 4.x to hidden.
dimitriskr → made their first commit to this issue’s fork.
Check this issue
dimitriskr → created an issue.
Add the details of
https://www.drupal.org/node/150220 →
as small comment, as that page is deleted
Archive
@john franklin, what about a modal? Do you think that's better?
I have some comments regarding the changes and then we can proceed
dimitriskr → made their first commit to this issue’s fork.
dimitriskr → created an issue.
I'll check how is it possible to use directly phpseclib/phpseclib and keep these encryption methods too
Other recommendations welcome
Thanks @gambry!
Do you have any ideas/thoughts for this module? My purpose is to replace the deprecated library, add some automated testing and make it D11 compatible
dimitriskr → created an issue.
Hi @maintainers
What's the status for maintainership? Are you OK with adding a co-maintainer to update this module for D10/11?
I want to use it in a project and can offer some time to update it
This replaces deprecated drupal_get_path() on ckeditor_find.install module with \Drupal::service('extension.path.resolver')->getPath() and that should make the module completely compatible with D10
dimitriskr → created an issue.
Updating patch to remove core: 8.x from .info.yml
Uploading the same patch for latest HEAD (1.0.0-rc9)
restored IS
My complete list
PHP 8.1.31
Dcore 9.5.11
views_data_export 1.5.0
views_data_export_phpspreadsheet 2.0.5
symfony/serializer v4.4.47 (part of it is \Symfony\Component\Serializer\Encoder\EncoderInterface)
phpoffice/phpspreadsheet 3.8.0
Reverting to v1.x, especially to 1.6.0 you released today, the error goes away, since the signature has now mixed $format instead of string $format in v2, where string $format gets us this error.
So, it's still OK for v1 but if anyone in D9 upgrades to v2(2.0.5), they will probably get that error
I have it updated. It's in 3.8.0
Currently version 2.0.5 supports D9 per the module's homepage and the bug is valid.
You could probably create a new release that fixes this specific error and then another one that removes D9 support.
But of course that's up to you, as a maintainer.
dimitriskr → created an issue.
Setting priority back to Major per #10
vensires → credited dimitriskr → .
dimitriskr → changed the visibility of the branch 3476166-deprecate-rolestorage to hidden.
dimitriskr → made their first commit to this issue’s fork.
dimitriskr → changed the visibility of the branch 11.x to hidden.
dimitriskr → made their first commit to this issue’s fork.
Added the constructor property promotion.
About the constructor docs, I cannot remove them because PHPCS will complain and tests will fail. Do I need to add a phpcs bypass for this to work?
@larowlan BC layer exists, it's crossed out because it is already done
Is it browser-agnostic? We have the same, but only on Chrome, Firefox works fine
Yes exactly
It becomes null because the argument starts with an invalid character and since the "Use multiple values" option is enabled, it tries to filter it for "+"(OR) and ","(AND) characters, anything else is invalid.
I think we need to re-evaluate the scope of the issue, per #57 comment, to filter out invalid characters in arguments (as an option in UI maybe, to cover all use-cases), and keep this feature disabled, in order not to break anything during updates. If this option is disabled, we show an error to the user, as is the current proposed resolution, and if it's enabled, no harm done
vensires → credited dimitriskr → .
system.install already checks for tokenizer extension here
@patelh84 can you upload an interdiff from #12? Thank you
dimitriskr → made their first commit to this issue’s fork.