🇺🇸United States @mortona2k

Something happening in the views display plugin, Table->setCell().
https://git.drupalcode.org/project/views_aggregator/-/blob/2.1.x/src/Plu...

By tracing the code with xdebug, I was seeing that the value gets rendered as markup, but then extracted as a string value before checking if the field isRenderable() and running renderNewValue(). The issue is somewhere in those functions.

I tested with this, to not process the title field on that line, and it rendered fine.

if ($field_name != 'title' && $is_renderable = $this->isRenderable($field_name, FALSE)) {

Not sure what else is wrong, but hopefully this gives the next person a better starting point.

Sorry, was actually not caused by this module.

mortona2k → created an issue.

Here's where the argument options are loaded in the settings form: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/views...

$relationship_options is empty when the view is aggregated.

The Author argument and Roles field are defined here: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/user/...

Setting $data['user__roles']['roles_target_id']['field']['no group by'] = FALSE allows selecting the relationship with aggregation enabled.

I'm not really sure what the implications of this are though.

This issue may be broader, I just encountered it with a Maximum grouping.

Working with an aggregated table recently I was able to hide the problem field, then add Custom Text field, add the token for the problem field to it and then it displays correctly.

This workaround was helpful.

This got it working for me, thanks!

I can't really account the parameter type question, but it looks like this change should be compatible with what's currently there.

There were changes to function definitions from the last commit on dev: https://git.drupalcode.org/project/views_add_button/-/commit/65bd7d0eb8a...

I think there are some differences between dev and the current release in the file you linked.

Since this MR also changes those, you probably want both.

There are two very different approaches in the patches here.

#11 has:

+    if (is_string($value)) {
+      if (strtotime($value) !== FALSE) {
+        $value = date("Y", strtotime($value));
+      }
+    }

This will convert date strings to year.

#18 has:

+    if (is_string($value)) {
+      $value = (float) $value;
+    }

This will convert a date string to to a number like 2025.0.

A patch in #3338895 has:

+    $value = round((float) $value, $precision);

Basically the same as #18, without the check for a string.

I bundled them all together and came up with this:

    if (is_string($value)) {
      if (strtotime($value) !== FALSE) {
        $value = date("U", strtotime($value));
      }
    }

    $value = round((float) $value, $precision);

Now a date string is converted to a timestamp. However, I'm not sure if this does anything for the max comparison, or if this just rendering the value afterwards.

Sorry, these are actually a little different, but overlapping. This one addresses invalid numeric field values, the related issue is about date strings, which can cause this error because they're an invalid number. There is a patch in there that has this code, however there is also one that tries to fix the dates as well.

The description and patch in this issue is the same as #3302573.

This bug is impacting everyone who has had to set up a view with this module.

The code change is a simple fix, and solved the problem for me on D11.

Thank you!

I'm getting this error on a fresh install on Drupal 11.

All I did was create a view, and enable this display. I'm unable to get past the error with any settings.

I think we should use the Enabled modules list, instead of the modules, which can take a while longer to load.

We'll need a link to create documentation in the Enabled modules report. Looks like the code is supposed to do that, but I only see existing ones.

Display the module enable history in the report.

Remove the links

- which ones?

I applied the patch to the 2.x branch and pushed it as MR7. But looks like I forgot to set the MR to merge into 2.x. Just did that.

Closing in favor of: https://www.drupal.org/project/faker/issues/3529201 📌 Support Devel Generate >5.1 Active

It looks like the change was made in https://www.drupal.org/project/faker/issues/3503237 🐛 Unable to access the Devel Generate Content and Generate User Settings forms after enabling Faker module Active

I think Devel Generate code was modified after 5.1, and the linked issue patched faker for compatibility with the previous version.

We should create a 3.1.x branch for compatibility with >=5.1.

Fixed by checking for status field.

Actually this is for the Replicate Actions module.

mortona2k → created an issue.

mortona2k → created an issue.

Pushed the fix.

Sorting the field machine names was easy, and a big QOL improvement when you have lots of fields.

We could check this MR in now and improve it further later. Or create a separate issue?

mortona2k → made their first commit to this issue’s fork.

Add instructions for dialog options.

I figured out how to do this and added a patch for Views Add Button.

The trick was to call Drupal.attachBehaviors(element) after adding the dialog attributes to the links.

I will follow up on this work in https://www.drupal.org/project/views_add_button/issues/3529307 ✨ Open in modal and reload view with ajax Active .

Currently, I'm able to set up an Add content button in the admin content view that can load the content add page, select a type, fill out the form, and refresh the view.

There is already an Add content action button on that page, which can be set up to use a dialog with Admin Dialogs. This script would be useful in the same way, to ajaxify the links on the page and allow the form to load in the modal.

https://git.drupalcode.org/project/views_add_button/-/blob/978b1d92cb8d1...

Added dialog options.

I am seeing the buttons as user 1 at least, but the current code is clearly flawed and the patch corrects it.

Here's a working proof of concept. It uses a form alter hook (currently only articles) to add an #ajax handler to the submit button to close the modal and refresh the view after submitting.

But I have an error when ckeditor is in the form, so hide the body field before trying this.

Here's the error:

Uncaught TypeError: dialogSettings is undefined ckeditor5.js:681:23

We can configure the attributes we need for the modal in the settings form so I wouldn't need Admin Dialogs, but the drupal.dialog.ajax library needs to be loaded. That could be set with a checkbox on the config form.

Looks good.

Here it is in claro.

And my custom theme, with overridden css, I had to update the show hide of the new element in the media query. (rotation not added)

Great, it installed. I'll try it out next time I need to do an import. If you want to close this ticket, I will follow up if I find any issues.

mortona2k → created an issue.

I added an issue for opening the entity add page to get the full list of bundles, with descriptions, which can be helpful for content entry: https://www.drupal.org/project/views_add_button/issues/3529943 ✨ Link to entity add page without bundle Active

Still using Admin Dialogs for the modal. It's working, but the links redirect to the entity form instead of reloading in the modal.

To fix, each link needs to have the use-ajax class, and drupal-dialog-type="modal".

I tested this by modifying template_preprocess_admin_block_content(), where the links are generated. It works!

To implement, we could add some js to add the attributes when the modal loads.

I pushed up plugins for Node and ECK.

To use them, select any bundle, it will just be ignored in the url generation and access check.

mortona2k → created an issue.

I was able to set a variable with {% set pageContent %}

text goes here

{% endset %} syntax, declare a pageContent text control, pass pageContent into the story as an arg, and print the html with {{ pageContent|raw }}.

The storybook control contains the html as text, but renders as markup correctly.

+1

Does anyone have advice on how to set up caching on a dev site so it's usable? I have all caching disabled, and the UI Styles form can take a while to load each time.

mortona2k → created an issue.

I am currently using this on several sites without issue, combined with Entity Prepopulate → .

Example: article={{ raw_arguments.field_article_target_id }}

mortona2k → created an issue.

mortona2k → created an issue.

mortona2k → created an issue.

mortona2k → created an issue.

mortona2k → created an issue.

Patch fixed it for me, with the simple case from my comment above.

Code change looks fine, but I'm not sure what variations of data will be seen here.

I'm working on a minimalist theme that works as an admin theme. It's a bit of a hobby project, but I would like the ability to disable the notice, if added.

More preferable, I'd like an easy way to implement a working display in my theme. I currently have a few hacks in place so I can use it, but it's still buggy.

I'm not sure if it's possible to code a compatible widget without considering the theme it will be rendered in, but I'm thinking along the lines of an SDC with self contained styles via css scoping.

Just thinking out loud, not to hold up progress on this issue.

I'm seeing a vertical scroll when the month view is at a narrow width. If I set the ratio low, like .5, it stretches it out too long.

More clarity/control over this would be much appreciated.

Is the code in here helpful? https://www.drupal.org/project/fullcalendar/issues/3527506 ✨ Extensible javascript FullCalendar object. Active

Workflow has a 2.x release now.

mortona2k → created an issue.

mortona2k → created an issue.

I don't think the profile I created is being called when I use drush genc.

[warning] Undefined array key "faker_profile" FakerContentDevelGenerate.php:45

mortona2k → created an issue.

This fix is working for me.

The code just uses the start date if the end date is empty.

I don't know enough to verify further, but this seems better than how it currently is.

I had this error, and I had Storage Entities installed, but after uninstalling Storage Entities, I still have the error.

I'm able to create a new project, install Storage Entities, add a date (only) field, and set up a fullcalendar view.

Disabling ajax fixes my broken view.

This seems like an issue with ajax, unrelated to Storage Entities.

Are these duplicates?

Ok I see it in D11.

I don't see it in D10, and the add block dialog is missing the list.

I'm unable to reproduce this with ckeditor 4 or 5.

The dragging UX works as described, but I don't see the media getting copied.

Tested on D10.

mortona2k → created an issue.

mortona2k → created an issue.

This fix was added to the last release.

I believe this is a support request that has been resolved, not an actual issue with composer/dependencies.

I had no issues installing this modules for a recent project.

Big +1 for this.

mortona2k → created an issue.

This isn't working for me, still getting the warnings.

Is there an issue with how ModuleHandler->invokeAll() is calling the function?

I'm using UI Icons Menu to select an icon for the top level link. I used and want this to be the trigger for opening the menu.

Whether the top level links are real links is a big consideration for design/ux/implementation. What we configure in the menu settings vs block config is also a ux issue.

So I don't think we always want the link to be tappable when it's supposed to be a link, but it would be good to have the option.

mortona2k → created an issue.

mortona2k → created an issue.

I made some improvements, let me know if you spot anything else.

I hacked the classes that were throwing errors, and hardcoded my powertagging_id, and was able to load the form.

mortona2k → created an issue.

heatherwoz → credited mortona2k → .

mortona2k → created an issue.

I added steps to create a view that triggers the error and is fixed with this patch.

mortona2k → created an issue.

Starterkit already has a dialog library that extends core/drupal.dialog, so I was able to just add the js in there for my theme without the library info hook.

https://git.drupalcode.org/project/drupal/-/blob/11.x/core/themes/starte...

I ran into this error, but replacing my site config with the default media library view fixed it.

I had changed the view display to use responsive grid.

But that display doesn't support row classes, relating to https://www.drupal.org/project/drupal/issues/2474491 →

I made a custom display that extends responsive grid to add custom classes back in, and it's working again.

Switching to select2 makes sense, and the patch looks good to me.

Works for me. Thanks!

Drupal's copy of jQuery UI Dialog is modified.

This line says it converts percentage to pixels: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/misc/dialog/d...

Nice find @james.williams, I think your analysis is correct.

Seems like it happens when the height of the dialog exceeds the height of the screen. On a fresh install my first media upload didn't trigger it, but opening it a second time with a media item in the library causes the scrolling.

Here's an old post where someone claims a dummy link worked: https://forum.jquery.com/portal/en/community/topic/default-scroll-positi...

I've been trying some related things but they're not quite working.

I also tried https://www.drupal.org/project/dialog_native →

Doesn't seem to have this problem, but the default styles need adjustment.

Tested on a fresh d10 site:

 [error]  TypeError: Drupal\Core\Plugin\Discovery\AnnotatedClassDiscovery::__construct(): Argument #2 ($root_namespaces) must be of type Traversable, null given, called in /var/www/html/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php on line 313 in Drupal\Core\Plugin\Discovery\AnnotatedClassDiscovery->__construct() (line 56 of /var/www/html/web/core/lib/Drupal/Core/Plugin/Discovery/AnnotatedClassDiscovery.php) #0 /var/www/html/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(313): Drupal\Core\Plugin\Discovery\AnnotatedClassDiscovery->__construct()
#1 /var/www/html/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(337): Drupal\Core\Plugin\DefaultPluginManager->getDiscovery()
#2 /var/www/html/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(213): Drupal\Core\Plugin\DefaultPluginManager->findDefinitions()
#3 /var/www/html/vendor/chi-teck/drupal-code-generator/src/Command/PhpStormMeta/Plugins.php(41): Drupal\Core\Plugin\DefaultPluginManager->getDefinitions()
#4 /var/www/html/vendor/chi-teck/drupal-code-generator/src/Command/PhpStormMeta/PhpStormMeta.php(73): DrupalCodeGenerator\Command\PhpStormMeta\Plugins->__invoke()
#5 /var/www/html/vendor/chi-teck/drupal-code-generator/src/Command/BaseGenerator.php(115): DrupalCodeGenerator\Command\PhpStormMeta\PhpStormMeta->generate()
#6 /var/www/html/vendor/symfony/console/Command/Command.php(326): DrupalCodeGenerator\Command\BaseGenerator->execute()
#7 /var/www/html/vendor/symfony/console/Application.php(1078): Symfony\Component\Console\Command\Command->run()
#8 /var/www/html/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand()
#9 /var/www/html/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun()
#10 /var/www/html/vendor/drush/drush/src/Commands/generate/GenerateCommands.php(105): Symfony\Component\Console\Application->run()
#11 [internal function]: Drush\Commands\generate\GenerateCommands->generate()
#12 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array()
#13 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback()
#14 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter()
#15 /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process()
#16 /var/www/html/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute()
#17 /var/www/html/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run()
#18 /var/www/html/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand()
#19 /var/www/html/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun()
#20 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#21 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#22 /var/www/html/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run()
#23 /var/www/html/vendor/drush/drush/drush(4): require('...')
#24 /var/www/html/vendor/bin/drush(119): include('...')
#25 {main}. 

This is a UX issue. I'm still hopeful that something can be improved.

I did not know that you could modify the body or another field and then click save, that is working for me.

Is it possible to put an alert on the preview page when you click back?

Is it possible to check on the entity form if you've used the browser navigation to get here (I've never looked into this). There might be some indicator we could check.

mortona2k → created an issue.

My first instinct was to agree with @ressa.

CRM = Customer Relationship Manager. This is a well established term, like CMS.

However, CiviCRM refers to itself as a "Constituent Management System".

We could argue that semantically, "Contacts" is inclusive of "Customers", and so it is an expansion of the concept.

Although this only changes the intended purpose, not necessarily the feature set. A full suite of standard CRM tools would work for customers, constituents, and contacts.

Good thing those all start with C!

(I asked GPT for clarification/ideas: https://chatgpt.com/share/681a1f4d-bea4-8011-a184-9865b72e7b78)

That says it's ok to bend the C, and also suggested Community Relationship Platform.

The patch is now quite different than the line it applies to, and I think it's no longer relevant.

https://git.drupalcode.org/project/formtips/-/blob/8.x-1.x/js/formtips.j...

var $descriptions = $('.form-item .description,.form-item__description,.form-item .filter-guidelines,.fieldset__description')
  .not(selectors)
  .not('.formtips-processed');

However, I am still having some issues. I'm getting a formtips wrapping vertical tabs, and my fix above disables all tips, not just on fields inside the vertical tabs.

This patch was needed for the continuous scroll formatter to work without errors.

After setting up the repository in my root composer.json and requiring mozilla/pdf.js, the module is working for me.

Any reason not to merge what we've got? It should be set up to load the library automatically, right?

Having the module define the asset repo as a package in composer.json and requiring it should work.

If not, the instructions to set up composer.json are working fine and could just be pasted into a README.

@geoffreyr - use the composer why command (see the example above).

Or try why-not <package> <version>.

Hello, I suggested looking into this from the related ticket.

I'm interested in improving the site documentation experience, to make things easier for clients and developers as projects grow over time.

I've used both these modules a little so far.

Module Usage Documentation is great for taking notes on why I installed a module and how it's in use. This knowledge is very valuable years later, for example, when I need to know whether it's ok to disable for the sake of a D11 upgrade, or if I should wait for compatibility.

The tricky part is remembering to use it! I think some UI improvements could surface more info and encourage developers to fill it out.

I used Content Model Documentation as a tool for analyzing site structure during upgrades or extension projects. I'd like to start using it from the start of projects to document things from the ground up. It seems like there is a lot here that could help out a lot, but again more UI improvements are needed to smooth out the experience.

One quick opportunity for the combination of these modules is that the CMSD module report loads very quickly compared to the full extension page, so it would be easier to edit CMD info there.

Thanks!

mortona2k → created an issue.

+1 for this.

Currently, you have to navigate to Structure > CM Documents, select a field and add the documentation.

Then the field documentation appears in the content type documentation tab.

Would be great if it was a little easier to edit, and displayed in more places like the manage fields/display tabs on the content type.

Here's what it looks like with documentation created for one of the fields on Page:

mortona2k → created an issue.