This doesn't apply cleanly to beta4. It applied to beta3, but applying https://www.drupal.org/project/cer/issues/2846318#comment-14841353 📌 Complete Synchronization functionality for existing reference values Needs work beforehand would also have it fail to apply.
Patch no longer applies cleanly to beta4. I tested it against beta3 and it did apply cleanly.
While this isn't really worthy of a major version, in theory this could get bumped to 5.1 with a warning in the release notes to toggle bi-directional back on for all existing CERs. Not elegant or ideal.
I've been using this on 10.4.6 and it's critical for a use case moving forward.
Thanks for documenting the workaround.
Hopefully mandclu has some time to look at the issue queue at some point, but supporting open source on top of a dayjob is a rough task. :)
I'm not a maintainer, unsure if there's a slack channel but I don't think so, nothing showed up in a quick search on drupal slack.
The more information page should send you to the docs for fullcalendar (the actual javascript library), basically the values input into settings just get sent to that. If those two options aren't doing what they should be doing, you could check to see if they're wired up correctly in the module and/or create new issues. Mandclu who created the most recent version of this module seems to be busy at the moment.
You're welcome. :)
My guess is that going off how it used to be implemented might be more work. You may very well be able to just do a copy and then replace variable names etc for an existing setting in this branch - all the module is doing afaik is passing a value input in the drupal settings to the fullcalendar js library that generates the calendar.
Not sure what accordion it'd fall under in terms of organization. Date & Time settings I guess? It'd be useful as a public patch if you get it working as that seems like a not so unusual use case. :)
You could try switching between BEF & default exposed filters https://www.drupal.org/project/better_exposed_filters → and see if there's any change.
This is duplicate of https://www.drupal.org/project/fullcalendar/issues/3497050 🐛 Warning message on installation because settings form does not exist Active , but more focused.
The other issue also edits some labels.
Not a dev, but looking at fullcalendar's docs what you want is to pass a value to https://fullcalendar.io/docs/defaultTimedEventDuration
You could look at the structure of the rest of the settings, pick one to modify to pass values to this value in the event model.
Marking this as a duplicate issue. See:
https://www.drupal.org/project/field_group/issues/3333953 🐛 Nested field groups improperly display as "Disable" in the admin UI Active has a manual workaround
https://www.drupal.org/project/field_group/issues/3085858 🐛 Drag and drop acts weird, sometimes not resetting the parent, or even clearing the region value Needs review has a patch
people mentioned this patch worked for them https://www.drupal.org/project/drupal/issues/3089151 🐛 TableDrag JS :first-of-type issues Needs work
As a workaround for this, you can disable drag and drop and then manually select a tab to go from disabled to content when in the sort by weights mode, save the form, and then go back to drag and drop.
It's a little annoying, but it works.
The workaround patch has been working for me for a while now, but it hasn't been tested by anyone else. I wouldn't say it is fixed, or RBTC, but neither is it active or needs work. Needs review seemed the best status as it indicates that the functionality is considered to be complete but has not been verified by a second party.
I considered putting the patch in issue 3490590, but any discussion about it would seem off topic to a proper solution. 3490590 was linked as a related issue to this one.
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.
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.
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?
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
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.
"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
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?
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.
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.
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:3I 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!