Minneapolis, MN, USA
Account created on 10 June 2006, over 17 years ago
#

Merge Requests

Recent comments

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Definitely needed and great work making this happen.

Looks like all concerns addressed and tests passing.

After this patch, the default behavior is the sameβ€” the country always shows in the address.

It adds, however, the crucial option, on a per-field on entity display settings basis, to "Skip country for domestic addresses":

And the address displays without the redundant country.

RTBC!

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Oops sorry misunderstood the patch. We have no need for this level of complexity. What would be the "Symfony Mailer way" (again, think this should be provided by the module always) to get the base URL available as a variable in the email template (e.g. email-wrap.html.twig) to have the base URL of the site, for example:

{{ url_site }}

(Don't want it hard-coded; it should match dev or test or live!)

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

For any HTML-formatted e-mail, having the base URL to be able to include theme assets is very common and needed (and not having this has been causing subtle breakage on a site migrated from Swiftmailer). I think this should go in Symfony Mailer itself, is that open for reconsideration? If not i would be able to make and maintain a separate project (anyone else want to co-maintain?) but again, for this particular variableβ€” feels like it should be available with no additional modules.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Does Empty Page need a 'modern Drupal' (8, 9, 10, 11…) maintainer?

Seems to have been updated but needs someone to cut release, continue to accept patches.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

mlncn β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Going to say it is related that we do not even fully document how to translate log messages: #3059567: DbLog doens't explain how to correctly translate log messages β†’

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

OK what we need here is a release and documentation.

The issue "Not working with your contrib / custom theme?" is fixed, but there isn't a release yet with that fix yet, so we need that, and then documentation updated to provide the option to "Override the field template for all themes." or to copy over fences module's field template to your custom theme.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA
πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Thank you mayurgajar and abhishek_gupta1 β€” i went with a Drupal function that does the same as date(). A nice followup would be to allow setting the date format.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

We add the token back, but do not show it as an option to avoid redundancy.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA
πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

The ff58e6e77aaee83058aa372dc41ba3cc757451a3 megacommit included a change from $donation->getDollarAmount() to $donation->getFormattedAmount() and also changed the associated token name to [formatted_amount] from [dollar_amount].

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Possibly related to πŸ› Function strftime() is deprecated Active ?

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

mlncn β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

mlncn β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Last two patches, reroll of the main approach in #79 and the alternate approach in #84 do not cover taxonomy terms.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Gently bumping this to major for all the above and for the following scenario, cannot save content with unpublished entity reference:

  1. An editor creates content that references a term or other content.
  2. An editor unpublishes that other content or term.
  3. An editor edits the content and cannot save it while receiving a baffling error: "Leadership (value 3)" and over on that field, "This entity (node: 792) cannot be referenced."

No further explanation to add "because it is not published." No link to the content that needs to be published to be able to save the current piece of content.

Even though the editor may have the permissions to fix the error themselves and try re-saving, they are often (repeatedly, even for experienced, motivated editors) unable to.

That's the experience using the default autoselect widget.

With the Inline Entity Reference it will have something like "Error message: 1 error has been found: Partners" and then repeat in four places on that field "This entity (taxonomy_term: 1582) cannot be referenced." (at the top of the field, for the "Add existing" autocomplete, below the "Add" button, and for the "Create new" buttonβ€” but not on the offending term, which does not have an ID next to it so it is even harder to identify the culprit.

Oh, and if the widget is a select list dropdown or checkboxes? The editor can save the content no problemβ€” the unpublished reference is simply removed. Boom, data loss!

Two very different scenarios, one leading people to be stuck unable to save content they have edited, the other silently deleting a reference, based merely on the form display.

So yes, it is of major importance that people be able to reference unpublished content, especially that they have access to. I'd like to add messages warning people that they have referenced unpublished content from published content (and Drupal will not display it), but that can and likely should be done in contrib.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Running into this in putting a Drupal.dialog (not ajax) in a contrib module.

This patch fixes it for me, but the fact that adding a dialog in my module triggered this problem in toolbar makes me wonder if i am not doing something to scope my dialog correctlyβ€” or if dialog has a bigger bug?

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Presently an easy but theming-required workaround is available: ✨ A themer can override In Other Words list templates for specific view modes and fields Active (in the 2.0.x and 3.0.x branches, only for regular entity reference lists (not sequential terms), and no release cut yet).

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

mlncn β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

This is not merely unintuitive/confusing, if this problem occurs, the UX is telling people they do not even need to look at this (as noted by geekygnr in #24 πŸ› Incorrect behaviour for block page visibility Needs work and alison in #26 πŸ› Incorrect behaviour for block page visibility Needs work ).

  1. Leave "Pages" blank.
  2. Have the "Show for the listed pages" and "Hide for the listed pages" radio buttons set to "Hide for the listed pages"
  3. The summary of Visibility will tell you Pages are "Not restricted" when in fact it is restricted so severely it will not show on any page.

Given that fixing this ought to change the behavior in the edge cases of blank lists, we should make that change, and so will also need an update hook to do so.

Even if we do not change stored configuration we should have an update that provides a link to the change record informing people the user interface behavior has changed (whether anything is updated or not). The update hook should further specifically alert people that the configuration they have may be leading to an unexpected result of hiding their block from every page, if they have 'negate' ('hide_on_pages' => 'Hide on specific pages') checked and the Pages textarea blank.

If we don't want to allow such a confusing case (the default of displaying everywhere is fixed by the 'Show on all pages' radio button in the patch) then we need a fourth radio button 'Hide on all pages' or we need to update such blocks to be disabled. (The latter is better in my opinion, provided we let people know which blocks were in such a state. But i'm not sure how that would interact with other visibility display settings, let alone more complex modules like Block Visibility Groups.)

Where does the logic to invert the standard behavior for a blank list actually happen? I know it's sort of common in Drupal but whenever it is also paired with 'Negate the condition' the double negative (negate an empty list that is interpreted as everywhere == hide everywhere) is bound to be counterintuitive anywhere it comes up. I cannot find it in core/modules/system/src/Plugin/Condition/RequestPath.php or core/lib/Drupal/Core/Condition/ConditionPluginBase.php (which provides negate as a default option) nor in core/lib/Drupal/Core/Path/PathMatcher.php.

Block visibility based on Vocabulary (using core/lib/Drupal/Core/Entity/Plugin/Condition/EntityBundle.php i think) has the same odd behavior (you can select nothing at all, choose negate the condition, and then the block is hidden everywhere) but at least it doesn't set any expectations at allβ€” no help text at all and no summary in the vertical tabs!

Some or all of my comments are probably for follow-up issues. A lot of work has been put into this, especially by paulocs; it would be wonderful to get this across the finish line.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA
πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

This fixes the JSON and is ready to go in!

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Not sure how all the upgrade compatibility bots missed this but hey, here we go.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

mlncn β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA
πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Made a 2.0.x branch based on all the work here and danheisel's fix. (Gnuget gave me maintainership a week or so ago; if anyone else has put themselves forward let me know!)

If no fatal errors found i think we can finally mark this fixed and keep anything else in follow-up issues.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

mlncn β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Provide a practical example of getting a route match parameter.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Rabbit Hole briefly had this feature but currently does not.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

First thing we (Louis) have realized is that rather than adding a field that is not going to be searched or filtered or faceted on in a Search API powered view can simply be left out of the search index, and instead the view can access it from "Example field" rather than "Example field (indexed field)" (that latter one would no longer show up in the Add field dialog on a view).

So hope that helps some one else too!

But there should be an option to not add a field to an index. One use case we ran into is easily / straightforwardly showing related fields of a piece of content in a view, which makes sense to do via Search API rather than a views relationship in a Search API powered view.

There are reasonable use cases (or at least one) for adding a field to a Search API index without wanting it to be … "indexed".

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

I think we ran into this on a project (on configuration import, many many errors about too many keys specified - max 64 allowed - for adding database indexes for columns in two different search_api_db tables that admittedly do have a ridiculous number of fields.

We will look into this further but any quick thoughts on this old issue?

Including the raw warnings here mostly to help other people who might run into this to find this issue:

 [warning] Drupal\Core\Database\DatabaseExceptionWrapper while trying to add a database index for column field_hh_cori_flag to table search_api_db_waitlist_status: SQLSTATE[42000]: Syntax error or access violation: 1069 Too many keys specified; max 64 keys allowed: ALTER TABLE "search_api_db_waitlist_status" ADD INDEX "_field_example_flag" ("field_example_flag"); Array
(
)
 in Drupal\search_api_db\Plugin\search_api\backend\Database->createFieldTable() (line 913 of /var/www/html/web/modules/contrib/search_api/modules/search_api_db/src/Plugin/search_api/backend/Database.php).
 [warning] Drupal\Core\Database\DatabaseExceptionWrapper while trying to add a database index for column field_hh_disability to table search_api_db_waitlist_status: SQLSTATE[42000]: Syntax error or access violation: 1069 Too many keys specified; max 64 keys allowed: ALTER TABLE "search_api_db_waitlist_status" ADD INDEX "_field_hh_disability" ("field_hh_disability"); Array
πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Yeah, it's a bad habit in documentation to not include the use statement, which in this case is:

use Drupal\Core\Form\FormStateInterface;

because they typically are placed at the top of the file.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

mlncn β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

drupal modules can require PHP modules (extensions) in composer.json, maybe we should also have a hook_requirements - https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Extension... - for Drupal install?

That'd be a separate issue though.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

I think a fix here would also fix a user experience (non performance) issueβ€” missing assets can result in a Drupal message about searching for it!

"The page you requested does not exist. For your convenience, a search was performed using the query themes+example+css+example+css+map."

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Awesome, thank you! Works wonderfully.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Confirming the same error, and that we can reproduce it at /admin/imce/browser β€” the module is definitely installed and present!

As was reported in the duplicate πŸ› Uploading with IMCE shows AJAX error Closed: duplicate the problem manifests to an editor uploading a file through IMCE as a pop-up box with an AJAX error:

An AJAX HTTP error occurred.
Path: /imce
HTTP Result Code: 500
StatusText: 500 Service unavailable (with message)
ResponseText: The website encountered an unexpected error. Try again later.

  • Drupal 10.2.0
  • PHP 8.1.26
  • Apache/2.4.57 (Debian)

Maybe switching to PHP Attribute based plugins would fix it: https://www.drupal.org/docs/drupal-apis/plugin-api/attribute-based-plugins β†’

But they are not supposed to have broken old plugins in 10.2! But it seems IMCE might not be alone in this regard: πŸ› Drupal\Component\Plugin\Exception\PluginNotFoundException: The "webform_file_validate_extensions" plugin does not exist Active

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

mlncn β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

This is a critical bugβ€” the maintainers should make a release of this module (double-checks real quickly to make sure i am not a maintainer of this module)

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

I've had core issue πŸ› Make the moderation control form an entity form so that it validates entities before save Needs work open as potentially related to this, not sure it is, but documenting here in case someone tackling this goes down the same path and finds it useful.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Cool, ultrabob! You are using a custom alter to hide the inapplicable transitions/buttons or some other method? Would be great to document or incorporate into the module. Also, made you a maintainer since you have been doing that issue curation work already thank you!

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

InaW are you able to re-test with the latest release? Not super likely but i'm hoping the changes in how we handle the buttons may have fixed this.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Yes, updated the module description. Thanks all!

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

mlncn β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Definitely agree that there's got to be a better, more universal approach (maybe we can keep track of what we want to remove, and only remove that?) but doing the fix this way for now, thank you ultrabob!

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Documented in README, thanks all!

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Thank you mikkmiggur, ultrabob, wlbryant, ras-ben, vodde83, and shubham_jain for your work on this!

Fix applied.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Making a release and i guess we can call this fixed for now, but surely we need something more to make this feature actually useful?

Realizing that same-to-same transitions really don't make sense when viewing a piece of contentβ€” "Save" (or even "Save as Draft") makes no sense when viewing, only "Publish" or "Unpublish (demote to draft)" and stuff like that makes sense.

Also, it does load maybe more than it has to starting from workflow_buttons_entity_view and src/Plugin/Field/FieldWidget for people who have no permission to edit (and so no permission to use buttons) that we could perhaps bail out of sooner.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA
πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

mlncn β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Patches / merge requests of course also accepted.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA
πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Committed

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA
πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

This error goes away when upgrading to the 2.x version, so maybe it simply needs to be documented that Drupal 10 sites should switch to 2.x?

(Or there was something specific to my setup causing this issue for me.)

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

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

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Long-term commitment to the module and a good plan! Endorsed.

AstonVictor have you contacted any maintainers through their contact forms?

https://www.drupal.org/user/366450/contact β†’

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

There is no direct Open Outreach to Drutopia upgrade path, but Drupal core's migration module provides the recommended way for going from any Drupal 7 site to any modern Drupal site, including Drutopia. See https://agaric.coop/blog/introduction-drupal-upgrades

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA
πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

mlncn β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Eight maintainers mostly means there's eight of us you can ask to get maintainership, so this issue shouldn't be needed lol. Of course it means we should be maintaining it well enough that it never goes up for adoption, but hey.

As no one has taken advantage of this issue, and i'm pushing out a release now, closing it, but please anyone who wants maintainership do ask!

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Not sure why Gitlab/Drupal won't show it, but the real work (by Gabor Szanto) is in the commit:

2023-12-01 Gabor Szanto Issue #3195515 by szantog, introfini, mlncn: Port D7 diff module integration to D8/9
2e971ca

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA
πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

Fantastic!

πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA
πŸ‡ΊπŸ‡ΈUnited States mlncn Minneapolis, MN, USA

The current experience in Drutopia is if the type or topic vocabularies do not have the term you needβ€”or even no term at allβ€”you need to exit content creation or editing to wend your way to the taxonomy section and add a term. Not intuitive at all.

Production build https://api.contrib.social 0.61.6-2-g546bc20