🇺🇸United States @erutan

I tend to not use Ajax unless I have a good reason to - it's odd in this case as the module is loading the javascript library for fullcalendar anyway.

On a local or dev server try disabling all other contrib modules and then try with/without Ajax? There's often some weird ajax errors when there's a lot of views centric contrib enabled. If that solves the problem, start enabling them until you find the problem one.

erutan → created an issue.

erutan → created an issue.

erutan → created an issue.

If anyone else has this issue, try mvonfrie's patch. If that works, let us know here, if not also let us know then try installing the module a few times, possibly opening the view display the settings in a new tab. :)

Updated the issue summary and added an extra paragraph at the bottom for context.

I don't think it's appropriate to make a MR at this time.

The current release is a different branch entirely.

It'd probably make sense to add a feature request for the 3.x branch.

@dlfaison the ajax/scrolling thing would be a separate issue - it has nothing to do with what you originally posted. If you keep on tagging unrelated issues onto an existing issue then there's no way to set the status of issues correctly - I'd edit the new issue out of this one and create a new issue. There shouldn't be exposed filters if you don't have them set up in the view. Do you have some other contrib installed that interacts with filters?

It sounds like reinstalling the module fixed your original issue? If not I'd recommend trying to apply mvonfrie's patch https://git.drupalcode.org/project/fullcalendar/-/merge_requests/55.diff

I'm able to scroll through a year or so worth of months with AJAX disabled.

The ratio values are just being passed into fullcalendar via it's API... that's how the JS works under the hood.

https://fullcalendar.io/docs/sizing

If you haven't figured this out yet, looking a bit wider the issue in fullcalendar itself (vs this drupal bridge / contrib) could be useful. Perhaps loading contentHeight as well as height would work via custom JS, or make a patch to include contentHeight in the UI?

$('#calendar').fullCalendar({
    height: 'auto',
    contentHeight: 'auto'
});

I just created a new fullcalendar view and can go into settings, make a change, and save the view fine. Existing views work as well.

What other views plugins do you have? I swear that sometimes VERF going bad on one view will impact another, and there's sometimes odd AJAX errors when you're running a lot of contrib.

Drupal 10.4.1
PHP 8.2.27
No smartdate

I'd recommend:

1) Try upgrading to Drupal 10.4.1
2) Look at the actual error in the dev console. This varies by browser but will be googleable.

Ah yeah, good catch.

Also interesting the account has existed for over 9 years but apparently hasn't been active for long.

As per the discussion at https://www.drupal.org/project/site_moderators/issues/3500259 💬 TATA Consultancy Services is bulk posting requests to gain maintainer access to modules Active this person should likely be removed as co-maintainer.

As per https://www.drupal.org/project/site_moderators/issues/3500259#comment-15... 💬 TATA Consultancy Services is bulk posting requests to gain maintainer access to modules Active I'm closing this.

I remembered this from a previous issue on Tablefield (which I felt had a great response):

https://www.drupal.org/project/tablefield/issues/3488566 💬 Offering to co-maintainer TableField Active

Looking at their profile, they were granted maintainership of blocktabs @

https://www.drupal.org/project/blocktabs/issues/3488855 💬 Offering to co-maintain blocktabs Active

Not from TATA, but a similar one credit on an automated security issue and then applying for co-maintainership.

I'll reopen that ticket on blocktabs and link back here. :)

FWIW I've been noticing a lot of offers to co-maintain large projects by new accounts with little contribution or history recently. The usual response is to participate in the projects issue queue, review some patches, fix some active issues, etc.

I've never seen anyone of the accounts in this pattern follow through. I assume it's for clout in terms of getting contracts, though it could become a security issue as well.

Thanks for sharing what you found out - while I know you were looking into taxo and don't expect you to develop outside of that itch does it seem this would also be the case for non reference fields?

I'll close this as a duplicate.

erutan → created an issue.

This still applies cleanly to dev, but ticking those fields and clearing caches do not hide existing tables with dummy "spacer" content.

As per: https://www.drupal.org/project/tablefield/issues/3385030#comment-15228612 💬 After upgrade to D10, empty tablefield output is displaying in paragraph on node Active I rolled back /src/Element/TableField.php from the commit before https://git.drupalcode.org/project/tablefield/-/commit/26d63be6aa25d34d1... and "empty" tables stopped being saved. The interface still spawns an empty table below one with content in it, but as there are no spacers inserted into it it doesn't get saved as content.

This is a pretty brute force approach (and I'm sure there's been updates to that file after this that need to pulled in) but I personally have no need to drag tables but would prefer them not being created every time an entity is saved.

It seems like it'd be simpler to just not save any tables/cells that only have the spacer in them, but there could also just be a patch that rips out the drag and drop stuff and keeps up to date with current changes to the file.

@thetwentyseven not seeing that on my side. Do you have steps to reproduce?

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

From a functional perspective this works on 10.3.10 when applied with the related fix in https://www.drupal.org/project/fullcalendar/issues/3241489 🐛 Fix fullcalendar_field_is_date() re: non-entity Views fields (e.g. 'Custom text') Needs review and there are no phpstan errors introduced. A custom field consisting of box text and a token of another field in the view was used and rendered properly.

Can't vouch if there's a tighter way to do it.

Airplane WiFi sucks but composer was finally able to patch the module. :p

erutan → created an issue.

Tested the issue branch with mandclu's commit and custom fields can be added to the view without errors and the view renders fine in Drupal 10.3.

That does look like a better approach to scope it. :)

erutan → created an issue.

Sorry about missing that - I have phpstan running in my dev environment again though that should have been obvious.

It seems the typo from ten years ago was putting [rebuild] on a new line (as well as duplicating it), rebuild seems to just be there to help restructure the data and then isn't needed after.

elseif (!empty($values['tablefield'])) {
      $values['rebuild'] = $values['tablefield']['rebuild'];
      $values['value'] = $values['tablefield']['table'];
      unset($values['tablefield']['rebuild']);
    }

The elseif statement below it only unsets rebuild.

elseif (!empty($values['value']['tablefield'])) {
      $values['rebuild'] = $values['value']['tablefield']['rebuild'];
      $values['value'] = $values['value']['tablefield']['table'];
      unset($values['value']['tablefield']['rebuild']);
    }

Does that seem right?

@lolandese any thoughts on this?

Sorry for taking a while to get to this. :)

It still applies cleanly to dev.

Tablefields still keeps adding empty tables every time I save an entity with a tablefield field with this patch. This happens with existing entities, new entities, entities with empty tablefields or ones with data.

This does clean up the following phpstan error:

------ -------------------------------------------------------------------------- 
  Line   modules/contrib/tablefield/src/Plugin/Field/FieldType/TablefieldItem.php  
 ------ -------------------------------------------------------------------------- 
  164    Cannot unset offset 'tablefield' on array<mixed, mixed>.                  
 ------ --------------------------------------------------------------------------

Makes sense to me. :)

This has been committed to the module already, should this just be closed along with https://www.drupal.org/project/fullcalendar/issues/3472260 📌 Cleanup PHPCS test Needs review ?

For native (non google calendar) events we'd need to target another field for the contents of the modal as well.

Thanks, this is a good thing to catch!

I got a white screen when adding a custom field without this patch when going to a view where a custom text field had been added, so it's more than an AJAX error.

While this does allow for a custom field to be added to a FullCalendar view without erroring out, the field cannot be used for the title. I'm not sure what other use case there is for one. Contents of a modal popup?

This technically solves the issue, but either a child issue should be created to address using a custom text field as the title or this should be changed to needs work. I haven't looked at the code at all.

FYI - it's not up to community norms to list your own work as RBTC, the idea behind it is that someone else confirms it works (hence the by the community part). :)

This works great, thanks!

Would it be more appropriate if the functionality of this patch was a submodule included with TableField?

If someone installs TableField Sort (or some other name) then we can have tablesorter installed as a dependency. This wouldn't impact people that don't want the functionality while making it simpler for those that do.

There isn't a stable build of tablesorter for D8+, but the 2.0 branch is up to RC2 and around a third of the people using the module → are running that branch.

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

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

"The module has no menu or modifiable settings."

/admin/config/content/tablefield exists.

Done. :)

I wasn't able to recreate the issue, but it applies cleanly and fixes typos with rebuild being repeated that would stop it from being applied to earlier levels in the array.

This should go into 3.0.x

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

There will be - there's currently one patch from the recent round of reviewing that is only in 3.0x because it breaks backwards compatibility with Drupal < 10.3 https://www.drupal.org/project/tablefield/issues/3472593. I'm going through some of the old needs review and RBTC patches to get them into 2.0.x before focus shifts to 3.0.x.

It wouldn't hurt to put up a beta 3.0x tag in the meantime though. Thoughts @liam?

The bugfix should be universally applied, the code cleanup is trivial but universal. It'd be nice to not have future patches have to deal with it (the capitalization of moduleHandler was fixed at least 3 times in different patches).

It's new functionality, but it's just an extra option on top of existing ones (and is very useful). It'd be nice to have it for 2.x so people with older versions of Drupal for whatever reason can use it IMO.

Params were copy-pasted from elsewhere in the document before.

Tests give the following new errors:

Drupal.Commenting.FunctionComment.ParamMissingDefinition at /builds/project/tablefield/web/modules/custom/tablefield/src/Element/Tablefield.php (485:3)
Drupal.Commenting.FunctionComment.ParamNameNoMatch at /builds/project/tablefield/web/modules/custom/tablefield/src/Element/Tablefield.php (488:6)

Fix formatting in patch on permissions.yml to match earlier code cleanup so it applies to dev.

Patch #7 applies cleanly to dev / RC2 and solves the issue. This is the most important patch,

The following two patches have already been implemented:

3170043-code-cleanup--fix-indentation-3.patch
3170043-code-cleanup--fix-capitalization-3.patch

The following patch applies cleanly:

3170043-code-cleanup--add-return-documentation-3.patch

The following patch has been confirmed that there is no add_row property and applies cleanly:

3170043-code-cleanup--remove-unused-property-3.patch

erutan → changed the visibility of the branch 8.x-2.x to hidden.

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

This looks like a duplicate of https://www.drupal.org/project/tablefield/issues/3321023 🐛 Error when deleting a tablefield RTBC , does the patch in that issue fix this for you?

erutan → created an issue.

FWIW I'm able to run cron with this module enabled on 10.3.10. The only patch I have now is the copy/paste one.

#19 is loading the JS lib, tr/td have a different background color and there are grey triangles to use as sort toggles, but it is not interactive.

The patches in this issue queue no longer work in Drupal 10.3.10.

#21 applied cleanly, but there were no options for sortable tables and no sortable tables automatically.

#19 popped up the following error multiple times when loading the entity with the field I want to sort in the admin edit interface:

Warning: Undefined property: stdClass::$field_tr_receiver_test_data_sortable in Drupal\Core\Entity\Sql\SqlContentEntityStorage->loadFromDedicatedTables() (line 1269 of /app/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php)
#0 /app/web/core/includes/bootstrap.inc(166): _drupal_error_handler_real(2, 'Undefined prope...', '/app/web/core/l...', 1269)
#1 /app/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(1269): _drupal_error_handler(2, 'Undefined prope...', '/app/web/core/l...', 1269)
#2 /app/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(503): Drupal\Core\Entity\Sql\SqlContentEntityStorage->loadFromDedicatedTables(Array, false)
#3 /app/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(428): Drupal\Core\Entity\Sql\SqlContentEntityStorage->mapFromStorageRecords(Array)
#4 /app/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(394): Drupal\Core\Entity\Sql\SqlContentEntityStorage->getFromStorage(Array)
#5 /app/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(312): Drupal\Core\Entity\Sql\SqlContentEntityStorage->doLoadMultiple(Array)
#6 /app/web/core/modules/views/src/Plugin/views/query/Sql.php(1632): Drupal\Core\Entity\EntityStorageBase->loadMultiple(Array)
#7 /app/web/core/modules/views/src/Plugin/views/query/Sql.php(1557): Drupal\views\Plugin\views\query\Sql->loadEntities(Array)
#8 /app/web/core/modules/views/src/ViewExecutable.php(1486): Drupal\views\Plugin\views\query\Sql->execute(Object(Drupal\views\ViewExecutable))
#9 /app/web/core/modules/views/src/ViewExecutable.php(1514): Drupal\views\ViewExecutable->execute(NULL)
#10 /app/web/core/modules/views/src/Plugin/views/display/Page.php(201): Drupal\views\ViewExecutable->render()
#11 /app/web/core/modules/views/src/ViewExecutable.php(1690): Drupal\views\Plugin\views\display\Page->execute()
#12 /app/web/core/modules/views/src/Element/View.php(81): Drupal\views\ViewExecutable->executeDisplay('storage_page_li...', Array)
#13 [internal function]: Drupal\views\Element\View::preRenderViewElement(Array)
#14 /app/web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(113): call_user_func_array(Array, Array)
#15 /app/web/core/lib/Drupal/Core/Render/Renderer.php(870): Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_ren...', 'exception', 'Drupal\\Core\\Ren...')
#16 /app/web/core/lib/Drupal/Core/Render/Renderer.php(432): Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array)
#17 /app/web/core/lib/Drupal/Core/Render/Renderer.php(248): Drupal\Core\Render\Renderer->doRender(Array, false)
#18 /app/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(238): Drupal\Core\Render\Renderer->render(Array, false)
#19 /app/web/core/lib/Drupal/Core/Render/Renderer.php(638): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
#20 /app/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(231): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#21 /app/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(128): Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
#22 /app/web/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
#23 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#24 /app/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#25 /app/vendor/symfony/http-kernel/HttpKernel.php(186): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view')
#26 /app/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#27 /app/web/modules/contrib/redirect_after_login/src/RedirectMiddleware.php(44): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /app/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Drupal\redirect_after_login\RedirectMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /app/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /app/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#31 /app/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#32 /app/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#33 /app/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#34 /app/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#35 /app/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#36 /app/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#37 /app/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#38 /app/web/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#39 /app/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#40 {main}

Furthermore if I go to edit a tablefield @ /admin/structure/storage_types/foo/edit/fields/ I get a whitescreen with the following:

The website encountered an unexpected error. Try again later.

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'foo_bar_sortable' in 'where clause': SELECT 1 AS "expression" FROM "storage_revision__foo_bar" "t" WHERE ("foo_bar_value" IS NOT NULL) OR ("foo_bar_format" IS NOT NULL) OR ("foo_bar_caption" IS NOT NULL) OR ("foo_bar_sortable" IS NOT NULL) LIMIT 1 OFFSET 0; Array ( ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->countFieldData() (line 1794 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

#17 applies cleanly to 2.4 and works great.

While manual entry would work for very small bits of info, and having the file uploads is great for more complex use cases, in ours we need to add in data produced by another program - copy and pasting is a lot simpler than generating a file and then attaching it. I'd recommend this get patched in. :)

That sounds like a good plan!

I'm hoping to get through testing some of the old RBTC and needs review patches for this project soon.

Thanks for the patch, I'll try and get this tested in a few days - things are hectic now.

Had this pop up and came to the issue queue. :)

I've had a few modules drop support for old point releases recently, so this seems fine.

It would be awkward for someone trying to install it on an unsupported release, but they shouldn't be doing that anyways. The patch you linked for D11 support is RTBC, so pulling in that and whatever other RBTC patches seem solid could make for a 3.0.

erutan → created an issue.

I'm currently evaluating options. Here's some more modules that do a similar thing - at least one has the ability to also download the source file (though it seems like you could use just make your own link from a block or view or something easily enough).

https://www.drupal.org/project/file_table_formatter →
https://www.drupal.org/project/blizz_table_field →
https://www.drupal.org/project/tablefield →
https://www.drupal.org/project/datafield →

I'd imagine it'd depend on the amount of time it'd take, but given this module exists because other contrib was not updating to v6 I'd say there's a good chance.

As per https://www.drupal.org/project/fullcalendar/issues/3475373#comment-15860986 ✨ Time format options Active times should now be able to be hidden, so it's really just the duplicate entries showing up. Anyone able to replicate this?

Another way of approaching this would be to respect the existing Date format select menu in Views and have this be passed through to the module.

Upgraded, testing against rc1 entries start and stop when they should! Selecting fields or not selecting fields doesn't seem to make any difference.

There are two issues:

1) Each entry shows up twice. I assume that this is because it loads a date field for the start, and then another one for the end.

2) Each entry has a 5p or 12a even though the fields are "date only" and don't have any time associated with them. I don't see an option for "all day events only" etc in the config settings, but regardless it probably shouldn't make up a fake time if none is present.

erutan → created an issue.

Taking a stab at expanding the title and issue summary.

Using a standard date field on that entity as start, then referencing a standard date field in a related (storage) entity leads to a blank calendar. I've tried selecting no date fields, one date field, and both. There are no other date fields in the view.

If I switch to unformatted list all the fields show up, so I'm not just messing up the relation.

If I have two dates on the same entity it's the same infinite past to present day list of entries. Again I've tried selecting no date fields, one date field, and both.

I'll second this, and also add that being able to use non-string fields would also be good.

Tested on beta6.

If I change the title field to an int field I get an ajax error. Changing it back to a string and saving stops it from occuring. This is a brand new mostly empty view created just to test this out, so there's nothing overly fancy going on.

fc/preview/page_1?_wrapper_format=drupal_ajax:1 
        
        
       Failed to load resource: the server responded with a status of 500 (Internal Server Error)
ajax.js?v=10.3.6:1219 Uncaught Drupal.AjaxErrormessage: "\nAn AJAX HTTP error occurred.\nHTTP Result Code: 500\nDebugging information follows.\nPath: /admin/structure/views/view/fc/preview/page_1\nStatusText: Internal Server Error\nResponseText: The website encountered an unexpected error. Try again later.TypeError: htmlspecialchars_decode(): Argument #1 ($string) must be of type string, Drupal\\Core\\Field\\Plugin\\Field\\FieldType\\IntegerItem given in htmlspecialchars_decode() (line 545 of modules/contrib/fullcalendar/src/Plugin/views/style/FullCalendar.php)."name: "AjaxError"stack: "Error\n    at http://FOOBAR.lndo.site/core/misc/ajax.js?v=10.3.6:196:32\n    at http://FOOBAR.lndo.site/core/misc/ajax.js?v=10.3.6:1921:3"[[Prototype]]: Error
    at http://FOOBAR.lndo.site/core/misc/ajax.js?v=10.3.6:196:32
    at http://FOOBAR.lndo.site/core/misc/ajax.js?v=10.3.6:1921:3

I think it's hardcoded to look for a string, changing it to a date gives me a similar error and if I directly visit the rendered view the following:

The website encountered an unexpected error. Try again later.

TypeError: htmlspecialchars_decode(): Argument #1 ($string) must be of type string, Drupal\datetime\Plugin\Field\FieldType\DateTimeItem given in htmlspecialchars_decode() (line 545 of modules/contrib/fullcalendar/src/Plugin/views/style/FullCalendar.php).

Changing this to another string field works (and it will fall back to name if empty, which is good and bad I suppose) but rewrites are still being ignored. Being able to rewrite a field seems like it'd be a fairly common use case.

I'm heading offline for a few days, but will get to this on the weekend or early next week. Thanks for the quick patch!

I did, it still did the infinitely long events ending at today.

I can go back and try again in a few days, but with either one or two standard drupal date fields added to the view it wasn't creating reasonable events.

I tested this on Drupal 10.3.6 and Editable Fields 1.0.2.

Both empty text area and file fields with "Form in popup" set would not update the contents of the page after adding in new content and submitting the form modal. This would solve an annoying issue!

erutan → created an issue.

erutan → created an issue.

Again, like any other Drupal module, anyone is more than welcome to contribute. In this case, the 6.x branch is open to anyone who want to contribute to that version which is compatible with the latest Fullcalendar.js. It is totally free to use 6.x.

It'll never have tagged releases or show up on the project page. I suppose pinning specific commits in composer is an option.

To those whom is interested in Fullcalendar.js 6, there are many other Drupal modules that have already supported it. Please give those modules a go before you considered the premium version here.

Sure, I'll give https://www.drupal.org/project/fullcalendar → a try.

erutan → created an issue.

Also curious. Running a scan via upgrade status showed two things to fix, one of which is just the version number in the info.yml file.

CONTRIBUTED PROJECTS
--------------------------------------------------------------------------------
Private Files Download Permission 3.1.1
Scanned on Tue, 09/24/2024 - 17:22.

1 error found. 1 warning found.

web/modules/contrib/private_files_download_permission/src/Form/DirectoryForm.php:
+---------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| status  | line | message                                                                                                                                                                                                         |
+---------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Fix now | 73   | Call to deprecated function user_role_names(). Deprecated in
drupal:10.2.0 and is removed from drupal:11.0.0. Use
Drupal\user\Entity\Role::loadMultiple() and, if necessary,
an inline implementation instead.
 |
+---------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
web/modules/contrib/private_files_download_permission/pfdp.info.yml:
+----------------+------+------------------------------------------------------------------------------------------------------------------------------------------------------------+
| status         | line | message                                                                                                                                                    |
+----------------+------+------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Check
manually | 4    | Value of core_version_requirement: ^8.8.3 | ^9 | ^10 is
not compatible with the next major version of Drupal core.
See https://drupal.org/node/3070687.
 |
+----------------+------+------------------------------------------------------------------------------------------------------------------------------------------------------------+

@mingsong "Again, if you just want that patch for your own custom version of this module, you can patch it in your own project"

The issue I see with that is that it is then a stranded fork, and everyone will need to manually pull in upstream updates etc into it, there's no means to coordinate issues regarding it that may come up in the future, etc.

I don't need any of the other functionality above, but it'd be nice to have the latest version of the library in a build that isn't stuck in time. If it's a reasonable one off fee that's something that would probably be worth it.

I do wonder how many people would use the paid version, and if having it forked off would impact the amount of community patches and people to test them etc.

IMO just having a new branch with the latest version of the fullcal library as a public branch, then selling a module with specific more advanced functionality seems the best way to go, especially if the work has already essentially been done. As you say, this is minimally maintained, so there shouldn't be a ton of new features and functionality coming in on top of that.

If someone with experience running modules comes and validates the MR for FullCal v6 and pulls in any related patches since, would that be enough to just have a new branch here?

The extra features in the paid version aren't of interest to me (no recurring events or rrules needs), since someone already wrote code for Fullcalendar 6 to work that seems appropriate to just put into a new branch if it's functional and then the bonus features can be added on top of that.

We're using the calendar as a simple visual tracker, it'd just be nice to have the latest version for UI / accessibility improvements. :)

I tried to install this patch via composer on the 6x branch, which led to some requirements conflicts. I just downloaded the code manually from the issue fork and dropped it in a local test instance, but I get ajax errors when editing a view for it and the calendar doesn't render on 10.3.1.

I'd love to try this out, mark it RTBC if it works and get a new version of this module out - is this still working for you dinazaur & MattDanger?

erutan → created an issue.

I'm not using ECA for anything involving anonymous users, but good to know about that issue.

I've disabled the module myself and am just going without comments on views until things clear up.

Tested this and the behaviour in the report is correct.

Made a quick update here https://git.drupalcode.org/issue/bootstrap5-3458182/-/compare/4.0.x...34...