A new test to ensure no XSS vulnerability with URL parameters has been implemented.
This new feature is released in 1.1.1
Thanks @mikey. I left a question about the URL parameters in the MR.
Once the concern is address, or if it is not an issue at all. The MR will be ready to merge.
The PHPUnit test to expose this bug has been done within the merge request.
mingsong → created an issue.
Thanks.
It seems that you are requiring a new feature that constraints the tooltip by language.
This modules just uses the path constraint implemented by the Drupal core.
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Path%21Pl...
Which is used by the Drupal block as well.
I change this to a feature request.
This module does not support Smart Date field.
Try https://www.drupal.org/project/fullcalendar → instead.
The 3.x develop branch download link.
https://www.drupal.org/project/entity_reference_tree/releases/3.x-dev →
poker10 → credited mingsong → .
@Kevin, as the error message provided in #16 suggested,
symfony/http-foundation[6.4.0, v7.2.0] conflict with symfony/cache <6.4.12|>=7.0,<7.1.5
So, that is one of the causes.
Back to your question,
@mingsong are you saying you were able to get simplesamlphp_auth to at least install with those aliases?
The short answer is No.
What I suggested in #15, is to use Symfony 6.4 instead 7.2. The big problem with this approach is how to test Drupal 11 and modules with Symfony 6.2. Which is way more complicated then to test the latest version of SimpleSAMLphp with Symfony 7.2.
So another approach is to still use Symfony 7.2. In order to test that, I think you need to (at least),
- Fork or patch SimpleSAMLphp to loosen its symfony/cache constraint to ^6.4 || ^7.2 (and any other Symfony components in the same boat).
- Point your drupal/simplesamlphp_auth to that fork or patched release via a path or VCS repository in your root composer.json.
- Run composer update --with-all-dependencies to let Composer reconcile everything.
Fixed in 5.2.4.
Thanks @Youri, good job.
Merging now as it is a blocker for D11.1 sites.
Thanks for reporting this issue.
The MR is ready for review.
mingsong → made their first commit to this issue’s fork.
mingsong → created an issue.
longwave → credited mingsong → .
I feel the same. I don't have the answer for that.
It is a question from the first place, why we need to limit the input value from 5 to -5?
Hope someone know the background can help us out.
Thanks @ressa, I updated the description as suggested.
Regarding the minimum value, I don't know if there is any use case needed a -10 finer value. I only tested 4 Google maps, which all have a small default zoom value.
As it will still be constrained by the min and max zoom value, I think it is fine to allow as small as -10 as the finer value. But I am not sure about that. I change to 'need review' to indicate that this issue needs review.
Regarding bypassing the version constraints by Composer, you can use the Composer's aliasing feature to allow you to complete the installation by using Composer. For example, in your local composer.json file you can add the following lines into the require section.
"symfony/cache": "7.2 as 6.4.0",
"symfony/config": "7.2 as 6.4.0",
"symfony/console": "7.2 as 6.4.0",
"symfony/dependency-injection": "7.2 as 6.4.0",
"symfony/filesystem": "7.2 as 6.4.0",
"symfony/finder": "7.2 as 6.4.0",
"symfony/framework-bundle": "7.2 as 6.4.0",
"symfony/http-foundation": "7.2 as 6.4.0",
"symfony/http-kernel": "7.2 as 6.4.0",
"symfony/intl": "7.2 as 6.4.0",
"symfony/password-hasher": "7.2 as 6.4.0",
"symfony/polyfill-intl-icu": "^1.28",
"symfony/psr-http-message-bridge": "7.2 as 6.4.0",
"symfony/routing": "7.2 as 6.4.0",
"symfony/twig-bridge": "7.2 as 6.4.0",
"symfony/var-exporter": "7.2 as 6.4.0",
"symfony/yaml": "7.2 as 6.4.0",
Please be advised that this is for testing purpose and not recommended for production. It aliases Symfony 7.2 components as if they were 6.4.0 to allow you bypassing version checks during the composer's install process. After that, you can test out if there is any compatibility issues with Drupal 11.
Created a MR and ready for review.
mingsong → created an issue.
mingsong → created an issue.
longwave → credited mingsong → .
This module doesn’t support the feature required.
Try the Fullcalendar Solr module instead.
From what I see, we got two proposed approaches so far.
@bryanmanalo, could you please create a new fork for your patch? We need the CI tests to make sure new changes won't create a regression bug.
If someone could create a new JavaScript functional test to reproduce this issue with CI, that would be great.
Thanks.
Released with the develop version.
https://www.drupal.org/project/entity_reference_tree/releases/2.x-dev →
Hi @Nick Abbott, thanks for your comment.
Can I take it that you tested the patch and the issue you came across solved by the patch in #8?
mingsong → created an issue.
It is aiming for the end of this year.
It depends on when we can get those issues solved.
The following new feature requires help on test, particularly PHP and JavaScript functional test script.
✨
Disable Verify button on first landing to the tfa form
Active
Change to 'Need work' as functional tests for the new feature required.
Thanks @Nadim Hossain for the patch. Is it possible to have functional tests for the new feature?
In a situation where there are multiple TFA methods enabled, the user might want to switch to another TFA method rather than Email. I think it is good not to send a TFA Email to user by default until the user explicitly click the 'Send' button.
The 'static' is a PHP keyword, not a class name. So in theory, patch #30 makes no difference from the latest version.
Can anyone confirm that the 8.x-1.6 working without the patch?
Thank you @Randal for the work here.
I leave a comment above for a clarify.
Also, I wonder if it is possible to have test script to test this function? Particularly, a test to make sure no access bypass with those changes.
Good points. Agree.
Good pick up.
Thank you.
mingsong → made their first commit to this issue’s fork.
Thanks @jlstrecker for raising this issue.
This issue (question) has been raised to Fullcalendar.js since 2015, almost 10 yers ago.
https://github.com/fullcalendar/fullcalendar/issues/2985
I understand the confusion and agree with that if we don't want to change the designed behaviour by Fullcalendar.js, we need to mention it in the document.
Speaking of document, I would suggest mentioning it in the user guide document → .
I apologise that I didn't reply it clearly. The reason why I don't think we should put this inside of the README.md file, is that the targeted audience of that file is a developer, since that file is hosted in Gitlab. Given that, I suggest putting it into the user guide document → .
I think everyone should have the edit access to the Drupal document.
I would vote for a document or amending an existing document to mention how to make the Fullcalendar work in this case.
This is the design behaviour of FullCalendar.
See below for more information.
I don't know why your custom entity need the '_type' at the end.
Let me take the Media entity from core as an example.
https://git.drupalcode.org/project/drupal/-/blob/10.3.x/core/modules/med...
The '_type' suffix is not mentioned in the Drupal entity API → , if we hard-code this in a contribute module, it won't work for others.
The bundle type is specified in the following line
https://git.drupalcode.org/project/fullcalendar_view/-/blob/5.x/src/Full...
And there is a setting to specify the 'Bundle type' to be created.
But it works with Node entity. Not sure about how it works with your custom entity type.
Drush command
drush fullcalendarview:generate --help
drush fcvg
mingsong → created an issue.
First of all, the user has to have the permission to edit that event.
And as mentioned that event has to be a whole day event, which means no time but only day.
Here is the view setting.
And the result
mingsong → created an issue.
Ok, first the selected nodes tip is required by others, we can't remove this feature. And second, I don't think hard-code the hight would fit all size of screen.
There is an error with the automated PHPUnit test.
1) Drupal\Tests\entity_reference_tree\FunctionalJavascript\BasicJavascriptTest::testEntityReferenceTreeJavascript
Behat\Mink\Exception\ResponseTextException: The text "Selected (3 of unlimited): Node 1 (1), Node 2 (2), Node 3 (3)" was not found anywhere in the text of the current page.
https://git.drupalcode.org/issue/entity_reference_tree-3197987/-/jobs/26...
Is there anyone know why? We can merge a MR that is failed from test.
IMO just having a new branch with the latest version of the fullcal library as a public branch
The answer from #7
The 6.x branch was created for catching up the latest major version of the Fullcalendar.js. It will be open and remain as long as anyone want it or contribute to it.
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.
The premium version of this module is not based on 6.x branch, which is totally refactored from 5.x.
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.
Sorry for commenting on a postponed issue.
I think the reason why the message rendered looks different between anonymous user and authenticated user is that there is another big-pipe placeholder callback was called prior to the call of Drupal\Core\Render\Element\StatusMessages::renderMessages(). That causes all messages were deleted in line 529 before the messages were rendered.
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/big_p...
Since the anonymous user won't have toolbar, the big-pipe placeholder for the message is the only one in that page, so that the renderMessages() is called before the messages were delete in line 529.
I've also just found some very strange behaviour where the new JS themed messages are not being used for anonymous users. Both for webform submissions and even password reset submissions they're unthemed.
We're using the same method as Olivero so I'm not sure what's going on here.
When logged in everything works fine.
@acbramley, If you turn on the Twig debug information, can you see what template is used for the status message?
According to my test with Drupal 11, the message showing to authenticated user is rendered from the core/modules/system/templates/block--system-messages-block.html.twig template.
Meamwhile, the message showing to anonymouse users is rendered from the core/themes/olivero/templates/misc/status-messages.html.twig template, which is the front theme in my test site. In your case, it might be from your custom theme.
I think that is why the result are diffferent between anonymouse and authenticated users.
@Sourojeet Paul, beautiful work.
Thank you.
I can't see which field is used for the 'Start date' from your setting above.
Without knowing the answers to the questions asked on #2 🐛 FullCalendar View not showing events (but list,grid,table view is showing) Postponed: needs info , there is no way to help you figure out what happened to your view.
Given that there are 5,361 sites using 5.1.14 and 2,389 sites using 5.2.1 till August 18, 2024, I don't think this is a common issue.
I change it to 'Support request' until we know what went wrong, because this issue sounds more like 'How to use it'.
Here is a help document on how to use this module.
https://fivejars.com/blog/all-you-need-know-about-fullcalendar-view-module
Hope it help.
Please provide more information to help the troubleshooting. Such as is there any error the logs? In the browser console(JavaScript error)? What is the field type of the 'start date' field? What is the view settings?
- I use the full page view to add an event and not required fields are also not appearing.
If the new event was created by double clicking on a date in the calendar, this module just simply open a new page with the populated start date.
https://git.drupalcode.org/project/fullcalendar_view/-/blob/5.x/fullcale...
In this case, the page URL is something like '/node/add/article?start=2024-08-01&start_field=field_start&destination=/calendar', and there should be no field hidden. I would suggest have a look at other module or theme that hide the fields from your node edit page.
- Do you have more info how to override a class? A link where to find an example?
https://www.drupal.org/docs/drupal-apis/routing-system/altering-existing... →
https://drupal.stackexchange.com/questions/81362/how-do-i-alter-the-rout...