Perth, Australia
Account created on 21 September 2006, almost 18 years ago
#

Merge Requests

More

Recent comments

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

The project is not actively seeking new maintainers.

Furthermore, there has been no active contributions from yourself indicating passion or competency with SMS Framework.

The offer is therefore declined.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Closing this for now as I believe its due to some bad custom JS...

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

drupal/gin 3.0.0-rc10

Tried releases 1.0.0-rc7 through 1.0.0-rc3.

More testing notes:

The add more button for multicardinality fields as provided by core, which triggers an ajax request and html modification, continues to work as expected.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

dpi β†’ created an issue.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Thankfully BCA doesnt reference IDs statically, i.e config (as in views plugin ID, block IDs), so it makes much sense for us. (Though even if others were to switch to classnames instead of IDs, its possible to shim with aliased classes or add BC ID-detection stuff)

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

No problem about timing, I just need it for selfish reasons right now. Plan to revisit with whatever goodness we get elsewhere + tests.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Sample exception:

BCA found Drupal\Module1\Entity\Document and Drupal\Module2\Entity\Media\Document
vying to be the bundle class media:document, but one does not extend the other, so a winner
could not be determined. Use the `priority` property on Drupal\bca\Attribute\Bundle with a
value larger than 0 to select which bundle should take priority.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Stop it.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

I havent reviewed the test, but can say the associated changes resolve tests where the Gin interface is involved. Particularly form submissions, resulting in the failure:

Behat\Mink\Exception\ElementNotFoundException: Element matching xpath "./ancestor::form" not found.

Thanks!

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

These are regular field widgets.

Go to the manage form display page for an entity.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Calendars are not within the scope of this project, as this project is simply for field and Drupal core accommodations for it.

I'd suggest asking (moving this issue to) an appropriate project.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Considering changing the order of constructor params so bundle is first.

Seems fine.

Using attributes without named-arguments is an unsupported pattern, imo, for backwards compatibility concerns.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

What does an integration look like?

What exactly does it do?

Why does it need to integrated on this side? Not theirs?

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

To me, it sounds like this is not within the scope of this project.

There should be a project dedicated to image derivatives, or Purge itself should support it, since it is a core feature.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia
πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

The motivation is good, however the implementation needs work

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

You're likely going to need to collaborate with whatever project is providing the purge capabilities for Varnish.

This project primarily deals with the entity side.

Given the patch looks very AI/ChatGPT'ish, I dont see any further value to this issue.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

dpi β†’ made their first commit to this issue’s fork.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Still getting a feel for this stuff with autowiring. I think this is fine, especially as PHPStan will pick it up.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia
πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

dpi β†’ created an issue.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

dpi β†’ made their first commit to this issue’s fork.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

update 2.5

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

If an entity type has all the right features enabled (interfaces, annotation, routeing etc) I think we can just enable it automatically.

For instance, Scheduled Transitions β†’ is a project I manage which automatically, and only, allows features for entity types if it has the right features. E.g all the interfaces and things required for Workflows and Content Moderation

But it would make sense to have some kind of switch regardless, either for a entity type or bundle.

I think this can be fleshed out as this is developed, however.

My target would be getting the Entity Test entities work.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

@marcoscano are you asking if there are other content entities that live standalone, just like a node?

I've worked on many projects, and can say there are many many instances of this.

If you'd accept the idea, I'll see if I can find some project time for it.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

The code is looking less insane with this revision.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

The pill markup adds quite large diffsize. Willing to do away with it and stick to a simplified version if we can keep the markup and layout/flexbox pieces, so we can potentially use the markup+selectors in extended/custom themes.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

dpi β†’ created an issue.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

This issue caused a break in πŸ› PageBlockDisplayVariant::__sleep() is no longer compatible with parent signature from ctools leading to PHP fatals RTBC . Mind reviewing that @japerry, since you're also a maintainer there.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Concise title.

Critical since it completely borks a site.

Proposed changes seem fine.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

A screenshot is not necessary.

Please do not spam tags. See [#3156530]

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

FYI tests are green over at ✨ Improve failure messaging Needs review . Notably had to remove core 11 testing due to entity usage.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia
πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Found issues with existing tests

  • Tests now use permission for πŸ› There is no way to delete file entities of other users Fixed (10.1 and later)
  • Entity usage updated to disable automatic tracking, so we have full control of the tracking values.
  • Cspell
  • disabled 11.x testing for now, until Entity Usage supports it
πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia
πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

dpi β†’ created an issue.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

dpi β†’ created an issue.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Deferring to @mstrelan + @acbramley as they are more active with Linkycosystem than I.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Does this mean we could deprecate the existing lazy proxy creation script

A worthwhile cause <3

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

We already support the nice thing, \Symfony\Component\DependencyInjection\Attribute\AutowireServiceClosure. AFAICT.

Symfony Docs

!service_closure should be avoided in new code.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

File was deleted?!

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

That's an example of Pareto principal. Just a few commands

This is exactly what I was thinking. Well put.

One thing I'd like see in this implementation is supporting command discovery in vendor directory. So you would be able bundle console commands to a Composer package (not Drupal module).

I've tried to address this in MR Notes ✨ CLI entry point in Drupal Core (Dex) Needs review . You can absolutely set up a command that exists in vendor (via services yml, etc). However autodiscovery is limited to the same rules as Drupal, i.e. only in module directories. Until Drupal has the ability to discover modules/plugins/etc I dont think it makes sense for this issue/initiate or related issues like ✨ Directory based automatic service creation Needs review to go out of their way and look in vendor. Its a large can of worms that doesnt need a decision now; we can easily change it in the future.

I've built a POC a few years ago.

Neat, I'm glad we've evolved even further since then. We're in such a nice spot in 2024.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Cleaning up markup

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

The intricacies of how to match versions in Composer with Drupal build system needs work, otherwise seeking feedback on the IS/proposal and the non Composer/build-system related pieces of the MR.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

dpi β†’ created an issue.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

exclude didnt work. Like I said, it seems to just translate to a 0 declaration under the hood.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Didnt work.

I think somewhere behind the scenes, in PHPCS, exclude translate to a regular <rule ...><severity>0 declaration.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

It should certainly do this by default.

I'm wondering if it existed before, or am I just misinterpreting the docs:

If there is a baseline file in the module it will use it, but if there isn't, it will just run default values.

And do docs need an update for this MR?

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

its a hint for both contrib, but primarily private projects who extend coder.

Private projects may choose to force strict types, and anyone who did so before this change will suddenly find that even if they have the rule declared, Coders' declaration overrides theirs. So projects and contrib need to make their declaration more specific, in order to override Coders.

Its more a PSA than anything. But, perhaps (unlikely) there was a way for coder to introduce this change without using the exclude directive.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Drive by code drop. Not working on this for now.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia
πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Created ✨ Add a Autowire trait for plugins Active , as an interim DX measure for all existing (legacy) plugins.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

dpi β†’ created an issue.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

dpi β†’ created an issue.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Just a note that if one uses the slevomat version also, multiple errors are reported on a line. One for each rule.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Note, the changeset introduced here prevents enforcing declare(strict_types) on files.

Per

<exclude name="SlevomatCodingStandard.TypeHints.DeclareStrictTypes.DeclareStrictTypesMissing"/>

in https://git.drupalcode.org/project/coder/-/commit/eb31ae916dcb6221e8783a...

To bring back the requirement, add this line:

    <rule ref="SlevomatCodingStandard.TypeHints.DeclareStrictTypes.DeclareStrictTypesMissing">
        <severity>5</severity>
    </rule>
πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Why a custom sniff over SlevomatCodingStandard.Functions.RequireTrailingCommaInDeclaration ?

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Core systems, for example LibraryDiscoveryParser, require libraries to be placed in the Drupal root or module-relative.

I have a project β†’ which dynamically determines the location of library files, for this example it is a test module in a subdirectory of the project.

The gitlab templates as they are right now keep the module files outside the Drupal install. Then symlink the module files to a typical location inside modules/custom via symlink_project

When PHP attempts to gets the location of the file, via reflection, it is outputting the true location of the file. That is, outside of the Drupal installation.

When I try to use code in CI, it will not work since the files lie outside of the Drupal install.

My guess is that there could be other Drupal projects failing, however unless assertions are very thorough, they won't notice assets are not loading.

--

My only suggestion at this time, is to actually copy, not symlink, files to the appropriate directory.

This could be done by further modifications to the project composer.json file, by adding a path repository, and modifying symlink_project.php to instead copy files.

Or we could just set up CI so it checks out the module code where it belongs in the first place, and build a running Drupal project around it (a few directories above). Im sure there are more ways to do this...

The code I used to workaround the problem can be found at https://git.drupalcode.org/project/pinto/-/commit/ac26e665ce5f703faffbda.... Note the changes to `.gitlab-ci.yml` and a creation of a modified symlink_project, at `.gitlab/custom_symlink_project.php` (which actually copies, not symlinks)

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia
πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia
πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

dpi β†’ created an issue.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

his might lead to confusion among users who might assume these configurations are mandatory for the module's functionality.

Well, there isnt a cost (in any metric) to filling these things out. To be honest I think we just need to document it clearly, per πŸ“Œ Add guidance to readme for how to find all three configs in GTM Active .

This way we do not need to work around different script configurations. After all, the guiding principle of this module is to be as simple as possible.

Also, filling these fields implicitly educates the developer that the environments can vary easily, making their CI/Testing/Nonprod setup clear.

In my opinion, this is a wont fix.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

dpi β†’ created an issue.

πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

Thanks @gapple, unfortunately I've been busy on other things so I havn't read above, and I'm good to delay work for now, as I'm using the original code happily on a project.

Production build 0.69.0 2024