@kksandr

Fixed in #3461212-6: FlagFollowerUITest failing since new access policy was committed to core →

I thought that an access denied would be sufficient to redirect to (or show subrequest of) the next path in the dynamic link

You understand everything correctly. All links in the specified order are checked for access and if there is an accessible one, it will be shown. If all links return access denied then the result will be an access denied. Are you sure that the next link in the list is accessible for the user you are testing?

If you are sure that the configuration is correct, then perhaps there is an error in the module, in which case it is necessary that you provide an example of the view configuration and dynamic link to investigate your case.

The edit has been corrected. Also, the test coverage has been updated to detect such cases.

I find this fix useless because I can't reproduce this issue on 7.0.0-beta1 or 6.0.6 following the steps in the issue. The patch looks like it disables this and makes this code dead, so yes it does solve the problem, but not very well. It's very strange that there is no test case here and the fix is ​​already merged and released.

Same problem, pager is broken after this fix. Rolling back to 7.0.0-beta1 also solves the problem.

@hmdnawaz I use phpredis, so it's class: Redis, which is the global class provided by that PHP extension.

This event was added to editors in version 8.0-alpha3~680 11 years ago, so it is compatible with Drupal 8 which the module claims to support.

kksandr → changed the visibility of the branch 2.1.x to hidden.

kksandr → created an issue. See original summary → .

This issue is still happening, I have added steps to reproduce it.

kksandr → created an issue.

@ddrozdik was there a response from @WorldFallz?

kksandr → created an issue.

I updated the steps to reproduce the issue according to the updated test and opened a merge request with the fix.

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

kksandr → created an issue.

I made the error message more descriptive using "Error::logException()". This will be useful because some exceptions do not have a message (as in the case of "FormAjaxException") and their cause is implied in the name of the exception class.

Yes, exactly them. Now I completely override the style library of this module like this:

:root {
  --hphp-color-comment: #696969;
  --hphp-color-red: #d91e18;
  --hphp-color-orange: #aa5d00;
  --hphp-color-yellow: #aa5d00;
  --hphp-color-green: #008000;
  --hphp-color-blue: #007faa;
  --hphp-color-purple: #7928a1;
  --hphp-color-bg: #fefefe;
  --hphp-color-fg: #545454;
  --hphp-border: 4px solid #d4d4d8;
  --hphp-indent: 0.5em 0.5em 0.5em 20px;
}

.dark-mode {
  --hphp-color-comment: #d4d0ab;
  --hphp-color-red: #ffa07a;
  --hphp-color-orange: #f5ab35;
  --hphp-color-yellow: #ffd700;
  --hphp-color-green: #abe338;
  --hphp-color-blue: #00e0e0;
  --hphp-color-purple: #dcc6e0;
  --hphp-color-bg: #2b2b2b;
  --hphp-color-fg: #f8f8f2;
  --hphp-border: 4px solid #43454a;
}

/* Comment */
.hljs-comment,
.hljs-quote {
  color: var(--hphp-color-comment);
}

/* Red */
.hljs-variable,
.hljs-template-variable,
.hljs-tag,
.hljs-name,
.hljs-selector-id,
.hljs-selector-class,
.hljs-regexp,
.hljs-deletion {
  color: var(--hphp-color-red);
}

/* Orange */
.hljs-number,
.hljs-built_in,
.hljs-builtin-name,
.hljs-literal,
.hljs-type,
.hljs-params,
.hljs-meta,
.hljs-link {
  color: var(--hphp-color-orange);
}

/* Yellow */
.hljs-attribute {
  color: var(--hphp-color-yellow);
}

/* Green */
.hljs-string,
.hljs-symbol,
.hljs-bullet,
.hljs-addition {
  color: var(--hphp-color-green);
}

/* Blue */
.hljs-title,
.hljs-section {
  color: var(--hphp-color-blue);
}

/* Purple */
.hljs-keyword,
.hljs-selector-tag {
  color: var(--hphp-color-purple);
}

.hljs {
  overflow-x: auto;
  display: block;
  padding: var(--hphp-indent);
  color: var(--hphp-color-fg);
  white-space: pre;
  background: var(--hphp-color-bg);
  border-inline-start: var(--hphp-border);
}

.hljs-emphasis {
  font-style: italic;
}

.hljs-strong {
  font-weight: bold;
}

But it would be great if a dark theme could be created by simply overriding variables by extending the existing library in the theme.

I came across this request several times, maybe someone else needs it, so I suggest introducing an option for this.

I tried to contact @WorldFallz but there was no response.
It seems that creating a fork is the only solution to continue support and development of this module.

kksandr → created an issue.

kksandr → created an issue.

kksandr → created an issue. See original summary → .

kksandr → created an issue.

@yospyn this fix targets the 11.x branch, which depends on PHP 8.3, so I used typed constants that are available in PHP 8.3. You can open a separate merge request for 10.3.x and lower the PHP requirements. You can also always update PHP on your server.

Work on the issue I mentioned in #19 continues here https://www.drupal.org/project/drupal/issues/3328425 🐛 CKEditor 5 balloons invisible when CKEditor 5 is used inside a modal Needs work so I return the status to "Fixed" since the original issue has been fixed, the variable has been renamed.

I moved the new service to the images module because it handles loading default images and checking access to them.

I don’t really understand why the session was used here, but it seems that every mail sending ends with logs being written and cleared, that is, there is no accumulation at the request level, so I’ll replace the log storage with a regular class property instead of a static one. If I'm wrong, the commit can be deleted.

d68ecfb4 - Issue #3458046 by kksandr: added test

Sorry, I pushed in the wrong branch.

I added a test that simulates sending mail to reproduce the error.

kksandr → created an issue. See original summary → .

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

Changes that I made:

1. Auto-wiring of dependencies
2. Dependencies were moved to the properties of the constructor
3. An interface was defined for the new service
4. Access check was moved to the service itself
5. The service uses entity_field.manager to get fields instead of loading only configuration fields
6. The access check now returns an AccessResultInterface, which makes it possible to provide cache metadata if it is to be used somewhere other than a file access check

I also left a few details for consideration tagged @todo.

kksandr → changed the visibility of the branch 2107455-102 to hidden.

kksandr → changed the visibility of the branch 2107455-image-field-default to hidden.

kksandr → created an issue.

I fixed the schema issues and removed unused keys in the schema.

I also fixed other tests that did not pass, this is out of scope, so if this is a problem I can remove it.

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

This problem has been fixed in the new version of the library https://github.com/patrickbussmann/oauth2-apple/releases/tag/0.3.0

I suggest overriding the --ck-z-panel variable without additional conditions

.ui-dialog ~ .ck-body-wrapper
This does not solve the problem if an instance of CKEditor was already placed on the page and after that the dialog was opened. Then .ck-body-wrapper will be before .ui-dialog

kksandr → created an issue.

This was solved here Theme library override can fail in when you have multiple parent themes 🐛 Theme library override can fail in when you have multiple parent themes Needs review .

kksandr → changed the visibility of the branch 2329253-allow-the-changeditem-11.x to hidden.

@longwave I opened a new merge request #8536, it has minimal changes.

All refactoring/optimization was removed, I also removed the validation omission during synchronization, this seemed unrelated to the problem.

But manually changing the request time instead of waiting in ChangedTestItem looked interesting, it might speed up testing a bit.

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

I believe that in any case we should override the pager with parameters from the EntityReferenceSelection plugin.

And the implementation of what is described in the problem will cause confusion for users who want to determine the limit of results at the widget level.

I opened a new merge request that solves the problem where if a view doesn't have a pager set, all results are displayed.

#54 appears to have dropped a good portion of the original patch

And this removal brought back the problem when the pager is not set, in which case the view returns all the results, instead of the specified limit in the widget.

kksandr → created an issue.

Thanks for the credit((

kksandr → created an issue.

Is there any hope that this issue will be addressed by the maintainers?