Adding credit for vandanasom.123 as for some reason it didn't get added automatically even though they made the MR.... Wierd
In the future please let the automation system move issues to "closed fixed" as per issue best practices
All I did was change the license that was added to composer.json given it was incorrect and used the one that is added by drupal's packagist magic.
Given that, since this issue was marked as RTBC before some support related issues from #19 on, I'm going to push this and get a new release out.
It is done
Hey in light of 💬 How to use? Active let's get strykaizer in here as he's already commented on it and some necessary fixes to make it work.
Over a week in and 2 yes. I wouldn't be able to get to either in a reasonable timeframe obviously.
Looking at the creds in your profile. I'm game. Would love to hear from one of the longer time maintainers like Joachim. Let's keep this open for 2 weeks per the typical project ownership guidelines and if we don't get a "no because" I'll grant you admittance.
generalredneck → created an issue.
I suspect this is because your minimal stability is set to stable. You may have to set that to alpha... though the composer dependencies in this case would be created by drupal's packagist magic. Another solution would be to require both commerce_pos and commerce_pos_keypad at the same version.
It appears this was resolved with the creation of 8.x-3.0
see https://www.drupal.org/project/commerce_pos/releases/3.0.0-alpha3 →
No problem. When I get a chance I'll get it merged in.
generalredneck → created an issue.
generalredneck → created an issue.
generalredneck → created an issue.
@dalin,
The first question is answered in the readme.
Only the most recent version of a node is reported on, so there is no
current focus on revisions.
No, it shows the sum of each bundle on each node. That may be a feature to ask for.
Rerolled with what was in 2.x
So container() is a private function, so I couldn't access it. That said, I had to increase the minimum requirements for this piece for Drupal 10.2. See the Change Record linked in the description.
I've tested this in both Drupal 10.3 and 11.0 and there were no problems. Gitlab_ci passed.
generalredneck → created an issue. See original summary → .
generalredneck → created an issue.
@thomwilhelm,
I think your patch contained parts of 🐛 update report data permission not working Fixed .
Implemented thomwilhelm's feedback into the MR. User 1 and role permissions are working as expected. Going to call this one good to go.
generalredneck → made their first commit to this issue’s fork.
Thanks a ton, marking as fixed.
If would check for !isset() or empty() in this case to make it more robust. we know that NULL == FALSE but not === as NULL is not . Also adding a comment so people understand why it's there.
@thomwilhelm,
Your patch doesn't apply cleanly against 2.x. I'm not sure, but you may have made the patch against 8.x-1.x?
In any case, I took my best attempt at merging what you had with what I had come up with before I found this issue. I added a configuration schema to square things away a bit too.
Care to give it a try? I used a different key name than you did when I initially did my changes. Let me know if it looks like I missed anything you had implemented.
generalredneck → made their first commit to this issue’s fork.
I pushed up the fix from ayush.pandey's patch because MR!12 did some reverts against some of the code changed in 2.x. Plus the patch works more completely.
Pushing the changes of MR!16 to 🐛 Why are entities saved in config ? Active
Hey, I appreciate both of yall taking a look at this. While identified areas where this would be a problem. I think the problem is bigger.
Specifically aisforaaron is storing the report state in the configuration entity. that does mean that any time you do a configuration export after content is updated (and you don't ignore this configuration entity) that it will be updated...
Example... after I run the report manually I get:
_core:
default_config_hash: WDVVbTde1eXP94qMDbx4NqQy4uOAEHLdyGsAcQBcF4o
content_types:
article: article
page: 0
hide_paras:
text: 0
import_rows_per_batch: '10'
watch_content: 0
report: '{"text":{"top":["1","2","3","4"]}}'
Prior to doing so, I get
_core:
default_config_hash: WDVVbTde1eXP94qMDbx4NqQy4uOAEHLdyGsAcQBcF4o
content_types:
article: article
page: 0
hide_paras:
text: 0
import_rows_per_batch: '10'
watch_content: 0
I propose that we use the State API → to store the report state instead of the Configuration Entity... and then we use abstracted retrieval of the state so that we can handle this error for all 3 places in one area. It's currently being handled inf ParagraphsReport::fetchJson(), but just not being used everywhere.
marking as fixed
I'm marking this one as outdated since it's for an old version and there hasn't been any movement here. I suspect that there wasn't an update to the configuration via an update hook given that it looks like this may be related to checking settings
In the words of HeMan
You have the power!
Sounds good. Never got anything from Kevin via contact form that I can find. Otherwise i would have done the same. Need to double check my notification settings on that issue queue cause I didn't see an email come through for the issue created
generalredneck → created an issue.
Adding a reroll for 10.3
I've had people here at work ask me "what are we patching". We are patching "symfony/framework-bundle" package with #31.
"symfony/framework-bundle": {
"#3452457: Fix Warming Up Route": "https://www.drupal.org/files/issues/2024-07-11/symfony_framework-bundle-fix_warming_up_routes-v6.4.9_backport-35d085d.patch"
},
Aknowledging mark_fullmer's message:
Reminder: the discussion in this issue does not involve code in the Drupal simplesamlphp_auth module. This is a discussion of a problem with Symfony and the SimpleSAMLphp library.
Don't let this backtrace full ya.
For those who need a text version of what callinmullaney posted in his image:
The debug information below may be of interest to the administrator / help desk:
SimpleSAML\Error\Error: UNHANDLEDEXCEPTION Backtrace: 1 src/SimpleSAML/Error/ExceptionHandler.php:32 (SimpleSAML \Error\ExceptionHandler::customExceptionHandler) [builtin] (N/A) Caused by: LogicException: The router "Symfony\Component\Routing\Router" cannot be warmed up because it does not implement "Symfony\Component\HttpKernel\Cache Backtrace: 6 /code/vendor/symfony/framework-bundle/CacheWarmer/RouterCacheWarmer.php:45 (Symfony\Bundle\FrameworkBundle\CacheWarmer \RouterCacheWarmer: :warmUp) 5 /code/vendor/symfony/http-kernel/CacheWarmer/CacheWarmer Aggregate.php:108 (Symfony\Component\HttpKernel\CacheWarmer\CacheWarmer Aggregate::warmUp) 4 /code/vendor/symfony/http-kernel/Kernel.php:552 (Symfony\Component\HttpKernel\Kernel::initializeContainer) 3 /code/vendor/symfony/http-kernel/Kernel.php:770 (Symfony\Component\HttpKernel\Kernel: :preBoot) 2 /code/vendor/symfony/http-kernel/Kernel.php:185 (Symfony\Component\HttpKernel\Kernel::handle) 1 src/SimpleSAML/Module.php:234 (SimpleSAML \Module: : process) e public/module.php:17 (N/A)
It might be good to have a task to rename the feature in other places, such as the tab on the content overview page. Going to put this in needs work for the tab name so i can at least remember we need to do this. Got this listed out in 🌱 2.0.x Road Map Active
I could get behind that. Not much longer. I was hung up on having "token" in there somewhere to describe what the list would contain.
I've marked this issue as fixed and added the following verbiage to the project page
If you are looking to install the Drupal 7 releases from this page, check out the All Releases → page to find the unsupported release, otherwise, drush make, and composer access is still available, Please note, you will receive a warning that these versions of the module is unsupported, and short of a major debilitating bug or security issue, there will be no maintenance by the module maintainers.
Hey there,
What has been done can't be undone. I'm sorry joseph.olstad.
Here's the message I get trying to restore the D7 release.
That said, I'll add some verbiage to the project page explaining that people can still find it under https://www.drupal.org/project/access_unpublished/releases?version=7.x → , but that we will not put any effort towards mantaining it unless there is a fatal bug or security issue raised about that version of the module.
generalredneck → created an issue.
I unfortunately can't go back and edit older versions, but I can however mark incompatibility going forward. The newer versions require Drupal 9.2 because of other changes as well.
I think this is the best I can do to resolve this issue. If you have better thoughts, feel free to reopen.
Currently, this module is only used to "view" existing content, not edit it or the like. Going to say negative to that as of now.
I believe this is a duplicate of ✨ Move Access Tokens UI to an entity Local Task / Tab Needs work . I'm going to mark it as such, but let me know if that's not the case.
@DamienMcKenna,
You have any thoughts? I noodled on a name for a while. Access Tokens is about as concise/meaningful as we can get without making that tab take up half the page.
Thinking of moving this into the new version and opening a new ticket for "moar better name" :D
generalredneck → created an issue.
I approve and good call.
generalredneck → made their first commit to this issue’s fork.
I don't believe the information here is relevant to this module. And the change to the module configuration settings form is no longer valid
@W01F,
Following up, Joachim was quick to respond. As far as we know there is no known limitation with last comment time. In what way are you using it and what results are you getting? What where you expecting? If we can reproduce what you are seeing we may be able to help.
clarkssquared,
I'm going to go ahead an merge the changes from cbfannin. If you by any chance wish to contribute fixes in the future for coding standards, feel free to open a new issue
paraderojether,
I'm going to go ahead an merge the changes from cbfannin. If you by any chance wish to contribute fixes in the future for coding standards, feel free to open a new issue.
As an FYI, any new release of drupal/core will create drupal/core-recommended with requirements of symfony at ~v6.4.8. So when 10.3.0 comes out for example (or a new beta), and someone is using drupal/core-recommended, a work around will be to use drupal/core instead and then pin the packages until this gets fixed upstream at simplesaml.
Truth... no. It's heavy handed. You can use one of the hooks to limit what data is stored. I'll sleep on it and work up a suggestion until I get you some 3.0 features worked out. Ideally you would only index the items that are referenced in views config. But at the moment you get every possible item that could be used.
Fixing a point
@paraderojether,
So, as a heads up, This module is using the default Gitlab CI for Drupal template. You can see it's installation as part of the repository, and the instructions used to install it can be found here: https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr → ....
That said, the phpcs.xml.dist used by the default CI is located here: https://git.drupalcode.org/project/gitlab_templates/-/blob/main/assets/p...
The command you used to check coding standards would not be equivalent to what was checked by CI, but goes above and beyond adding the DrupalPractice standards and additional file types.
While I appreciate any contributions that correct coding standards, Charles has satisfied my criteria for marking this task as complete. I'll leave the issue open for a few more days, as if you wish to receive credit for this issue, you will make the code changes you suggest as a Merge Request. If you wish, you may even add a custom phpcs.xml.dist that holds this module to the higher standards as a value add and ensure that Gitlab CI passes.
Thanks
@clarkssquared,
So, as a heads up, This module is using the default Gitlab CI for Drupal template. You can see it's installation as part of the repository, and the instructions used to install it can be found here: https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... → .
That said, the phpcs.xml.dist used by the default CI is located here: https://git.drupalcode.org/project/gitlab_templates/-/blob/main/assets/p...
The command you used to check coding standards would not be equivalent to what was checked by CI, but goes above and beyond adding the DrupalPractice standards and additional file types.
While I appreciate any contributions that correct coding standards, Charles has satisfied my criteria for marking this task as complete. I'll leave the issue open for a few more days, as if you wish to receive credit for this issue, you will make the code changes you suggest need to be made as a Merge Request. If you wish, you may even add a custom phpcs.xml.dist that holds this module to the higher standards as a value add and ensure that Gitlab CI passes.
Thanks
Odd. CI is running clean. Can you verify paraderojether, you are against the latest commit?
Functionally works on Drupal 11
All tests pass now https://git.drupalcode.org/project/datetime_now/-/pipelines/193947
Functionality was maintained.
generalredneck → made their first commit to this issue’s fork.
All PHPCS errors have been handled
https://git.drupalcode.org/project/datetime_now/-/jobs/1807044
That works now, Broken out fixes into
📌
Fix PHP Coding standards
Active
📌
Fix Javascript Coding standards issues
Active
While you are in there fix the cspell issue. webportal can be refactored into a different function name that has a valid English word. See https://git.drupalcode.org/project/datetime_now/-/jobs/1806925
generalredneck → created an issue.
generalredneck → created an issue.
generalredneck → created an issue.
generalredneck → created an issue.
Thank you all for your patience and work!