brad.bulger → created an issue.
brad.bulger → created an issue.
Will Contact → be the contrib module? And no work to migrate the current core module code to the contrib module will begin until 12.x is open, is that correct?
brad.bulger → created an issue.
brad.bulger → created an issue.
brad.bulger → created an issue.
The issue is that the mail_login AuthDecorator was returning FALSE if email logins were not enabled. I pushed a change to the issue fork branch to fix it. I am very new to working with issue forks, my apologies if it isn't set up correctly.
AuthDecorator::lookupAccount() is doing a check for blocked accounts that it doesn't need to. I left it there but as far as I can tell it could be removed.
This is a patch of the changes.
I see this in a Drupal 10.3 site using 4.0.3. We have no language issues or any other problems saving configuration. I just installed it and then turned off "Enable login by email address", and now valid usernames are failing validation.
I believe that in most of the cases where this error shows up in my logs, the client has made a GET request to /contextual/render. It looks like bots that are monitoring all the URLs accessed by a page request and trying to hit all of them. So they make a normal request to some page on the site, which triggers an ajax event that does a POST to /contextual/render, and somehow they see that URL and try to follow it.
I think it would be preferable to just silently fail in that case, versus the BadRequestHttpException. I certainly get a ton of these errors and they're effectively meaningless.
If it could automatically send the email when the form loads, that seems like what I'd expect. It doesn't have to be the only method enabled for the user.
But an explicit Send initially would be fine too. If the Send/Resend action was done with a link, always displaying the Verify button would be OK. If Send is a form button, it should be the only one at first. It could even be in a different form above the current one, since you want Verify to be first to be the default.
I am applying the patch in #20 to this contrib version of tracker, it works without issue.
I don't have any other similar modules installed, I just downloaded and installed this one, and the attributes I set on menu items are not saved. It is reading existing values from menu_link_content_data.link__options that had been set programmatically. When I set new values for attributes, nothing is changed in the db. The old values are still there.
I'm not sure what "CKEditor fields" are but nothing like the problem described is happening for me. This may be a duplicate of 🐛 Drupal core 10.3 breaks compatibility with CKEditor5 API Fixed or it may depend on a specific constellation of other CKEditor modules being enabled.
brad.bulger → created an issue.
brad.bulger → created an issue.
A colleague reports discovering a problem with require/require_once in 10.3. Our settings.php file requires default.settings.php and then adds some customization. What we found:
BUT instead it HAS TO BE
"require('default.settings.php')". During a cache clear request
\Drupal\Core\Site\Settings.php gets initialized twice (once before clearing,
once after). Each time Settings::initialize() invokes "require
sites/default/settings.php". It has to return the exact same information both
times. But the require_once line meant that the second time around it was
dropping default.settings.php.
brad.bulger → created an issue.
it's #1 that doesn't work. what permission are you granting? they can create relationships but that only allows them to add an existing group as a subgroup.
we want to give a member of ParentGroup A permission to create groups of type ChildGroup as subgroups of ParentGroup A and only those. not to be able to generically create a free-standing group of type ChildGroup, not to create any subgroups of any other ParentGroup.
at the moment the only thing we can do is grant the global Drupal permission to create ChildGroup entities to a Drupal sitewide role. even with that, the Create button isn't visible to them on the Subgroups tab, because they don't have the "create ggroup:etc" permission described in comment #1 (that path is the Create button path)
It's specifically the lack of create permission that we were hitting - group editors don't get the button to create new subgroups. Even if that user has a Drupal role granting create access on that group type, they get an access denied error on the link that would appear in the button. If we display the actual ultimate path for creating the subgroup, the people with Drupal permission can use that. So far there doesn't seem to be any way to give a group member access to create subgroups of that specific group only.
This is an AJAX callback in the form that is getting the name field value at runtime. Nothing is being written to the db. The relevant part is that $form_state->getValue('field_mynamefield') returns "_none" as the value for select list components.
What I'm not clear on is if that's intended. Does the change here only acts on submit or something like that. Should the value be "_none" or "" for field validation? For an entity constraint on the field?
I guess the change from blank to "_none" already went out in 1.0, I don't see any notes about the incompatibility change.
I am testing this using the MR diff as a patch on Name 1.0. We have code that runs in an ajax callback function that builds a fullname string to store in another field. $form_state->getValue('field_name') is returning "_none" in the array of components. So the name.formatter service's format() function treats those like strings - we get "_none John Doe _none".
Is this the intended behavior? Anyone else who was counting on empty components returning empty strings is going to have a similar incompatibility problem.
To #9, these aren't Drupal relative paths, they are HTML relative links. The href value does not start at the root of the site, it's relative to the current URL.
It is not a question of preference. /base and /base/ have different semantics. In many cases, the difference is unimportant. But it is important when there are relative URLs.
- child relative to /base/ is /base/child.
on https://my.site/base/ <a href="child">child</a> links to https://my.site/base/child- child relative to /base is (perhaps surprisingly) /child.
on https://my.site/base <a href="child">child</a> links to https://my.site/child
- When should I use a trailing slash in my URL? (Examples added)
For SEO, as far as I can tell, the important thing is to be able to have a single canonical version that you use throughout the site. Maybe any kind of global setting is in conflict with that. I don't think you can define aliases that end with a slash, so I don't know how you would be able to define one item as ending with a slash and another item not.
The path /group/[group ID]/subgroup/create is requiring create ggroup:[group type plugin ID] entity permission. Only admins can pass that requirement. This applies even though the user has access to /group/[group ID]/subgroup/create/[subgroup type].
brad.bulger → created an issue.
We could also copy the way that Block Exclude Pages → does it:
Basic example where a wildcard is used to display the block on pages under the user path:
/user/* <-- this will make the block visible on all pages under the path.
But let's say you want to exclude a specific page or another path directory under the path "/user/?":
!/user/jc <-- now you will be able to specifically exclude the "jc" page
or/and:
!/user/jc/* <-- exclude on all pages under "jc/?"
That changes what's there now, we'd have to convert any excluded form IDs.
Should this maybe be closed and another ticket opened? The change of status to "Needs review" implies that the changes are not yet released, but from what I can tell that's not true. I got the impression that 3.4 was a rollback of this, but it doesn't seem to be.
brad.bulger → created an issue.
I don't see the advantage. All this is doing is surfacing what was actually being done in the code, as far as only looking at form IDs that match those patterns (sort of - it would have matched on any form ID containing "user_", I changed it to match form IDs that start with "user_").
Being able to say "Match all of these except this one and this one" seems like a useful thing to be able to do.
I can tell you that it has nothing to do with DDEV, we are running Drupal 10.3 on Ubuntu / Apache and we see this error constantly. It's caused by bots making GET requests to /contextual/render. They seem to come directly to that URL, no referral.
Personally, I wish it would just return NULL or some such instead of throwing an exception. I don't know why bots are trying to crawl /contextual/render like that.
I've pushed some changes to the issue fork, do you want to review it there or as a merge request? I have not written tests for it yet.
There needs to be at least an item in the README file and preferably a config form.
The patch in #24 does not apply to 2.0.0 or to the current 2.x-dev. The patch from #20 still works.
Until I (or someone) gets a fork set up, this is a patch file that corrects the problems.
brad.bulger → created an issue.
brad.bulger → created an issue.
I am no kind of expert on image files or cameras but this is what the file command shows for one of the .JPG files that is giving us the 'Unknown format 0x300' error:
JPEG image data, JFIF standard 1.01, resolution (DPI), density 72x72, segment length 16, Exif Standard: [TIFF image data, big-endian, direntries=12, manufacturer=Canon, model=Canon EOS 80D, orientation=upper-left, xresolution=178, yresolution=186, resolutionunit=2, datetime=2019:05:16 23:51:45], baseline, precision 8, 3657x3033, components 3
That looks like a jpeg to me?
I am just wondering if in fact the two errors in the description both stem from the same problem, or if they are actually different problems.
Is this really only one problem? I never see the Canon error and I see the Unknown format: 0x300 error constantly.
I am getting this error on Drupal 10.3.10, PHP 8.2, Git Deploy 2.x-dev (2.5+1-dev). The patch fixes it.
brad.bulger → created an issue.
I recreated the patch again against 11.x. It applies cleanly to 10.3.x as well.
Where is my dashboard? Where do I log in? How do I use the site to actually do things, as opposed to browse it while waiting in the dentist's office?
reroll to apply to 7.103
Reroll of patch in #57 for 10.3.x
It doesn't seem like the documentation has changed at all? The video is no substitute as always, but I found it difficult to follow in its own right. It seemed useful for people who already understood everything about the previous version of the module.
What is "stackable"? Is that explained anywhere?
What is the partial split? Why would you use it? Are there any examples?
Trying to find any examples of the most basic cases, like having the Devel module enabled automatically on a local development installation, it seems like most writeups say they are for Drupal 10 but are actually documenting the 1.x version of the module. Or maybe not?
The workarounds are helpful, but the available tokens need to be expanded. For example, in Drupal 7 we were using %view-%exposed-%timestamp-full.csv for the filename. Including the query parameters - the %exposed filters - is very useful to have in the filename of the export.
I am new to composer and trying to update only core Drupal. I have both drupal/core and drupal/core-recommended in my composer.json file. Is that bad? Should it be only one or the other? I could not get it to update until I found a note in Slack that mentioned doing composer update drupal/core "drupal/core-*" and that worked. As far as I know this composer.json is what we got from drupal/recommended-project.
brad.bulger → made their first commit to this issue’s fork.
Maybe I'm misunderstanding the dismissal of the problem? I don't have a subdirectory in the URL to the site, it is just https://mydomain.local/, and when drupal_build_js_cache() tries to load the jQuery files, it is doing a file_get_contents() call on literally what is in the jQuery Update config - eg "/sites/all/libraries/jquery/jquery-3.7.1.min.js". That fails as you would expect.
to follow up, in our case, we got that same curl 60 error as a result of a firewall (from Fortinet, hence their cert showing up) that was blocking the domain it was trying to reach. nothing to do with certificates at all, only a misleading symptom.
we are getting this cURL error in relation to validating a remote video URL at youtube.com on a site running in a fake domain (the domain is only defined on our local hosts files at the server's IP). nothing suggested here is making a difference. trying to fetch the same URL that Drupal is trying to fetch gives this error from wget:
ERROR: cannot verify www.youtube.com's certificate, issued by ‘emailAddress=support@fortinet.com,CN=FG441FTK21900407,OU=Certificate Authority,O=Fortinet,L=Sunnyvale,ST=California,C=US’:
Unable to locally verify the issuer's authority.
I was getting the same error, and what fixed it for me was using www.googletagmanager.com rather than googletagmanager.com, even though theoretically the www. version is supposed to match the simple domain version.
I applied the patch but it did not change this - using googletagmanager.com in script-src-elem explicitly produced the same error.
It was being set in an included settings file.
brad.bulger → created an issue.
brad.bulger → created an issue.
The class Drupal\Core\Render\Element\FormElement provides a base class for form element plugins.
That is linking directly to a page from Drupal 8.7. That base class is deprecated, I believe - RenderElement and FormElement base plugin classes are deprecated and renamed to RenderElementBase and FormElementBase →
The replacement looks like it is \Drupal\Core\Render\Element\FormElementBase - I don't know if that's true or if there would be a better starting point to match the original intention, though.
This page used to be a useful partial list of element types
Form and render elements - 9.5.x - drupal
https://api.drupal.org/api/drupal/elements/9
But in version 10 it is reduced to one type, Component. Version 11 splurges on two types, Component and Ajax.
If there was some kind of link to some other place to find the information that would be one thing. This is subpar.
The Drupal API docs provides a comprehensive list of Drupal form and render elements.
No they don't. It's ridiculous how hard it is to find a list of form element types. I still haven't succeeded since Drupal 8 first came out. There are some partial lists in some places, maybe, though they change from version to version.
Ah ConfigImporter.php is from core, I was making assumptions. So even though I am trying to use the drush cdi1 command from config_devel to import a single config file, it is still going through some core stage that is having these problems?
brad.bulger → created an issue.
brad.bulger → created an issue.
That's interesting but I'm not sure how it relates to this issue?
There is another module, Log Entity Operations → , that has some capabilities like what the issue describes. It doesn't appear to be maintained.
Otherwise I think you would do grouping in the view. But I don't think there are any fields that tie changes together as being from the same update.
As of 2.3.0 at least, I'm running this module in a Drupal 10 installation with Drush 12.5.2.0, and I am not having any problems using drush. On the other hand, Drush doesn't see this module's generators at all. I started to try to write a new version but didn't get very far.
Should this issue be closed and a new one opened for the task of upgrading the generator code? Or repurpose this one? It matches the title but not the current description.
This information is missing from the 9.x API documentation as well now, for what that's worth.
This seems like a serious problem, in that most of the pages we look for in the API are implementations of something else, and because of whatever problem there is, none of them document their parameters, return values, etc.
Yes, this looks like it's working. I did a new install of Drupal 10 with ggroup 3.0.x and saw the original problem, then installed the issue fork branch. It only shows the types of subgroups that installed on the group type, and when there is only one it defaults to the form for it.
Domain Source isn't dependent on Domain Access (at least it isn't anymore). I separated the changes made for the fields of each module so that it will work for either or both.
There's an additional unrelated problem, that I have to fix to do anything about this issue. In DomainMicrositePathProcessor::processOutbound(), there is a line:
$domain_source = array_shift(array_column($entity->get('field_domain_source')->getValue(), 'target_id'));
The argument for array_shift() is passed by reference, so it has to be a variable. The array_column() call has to be stored and then passed to array_shift().
$target_ids = array_column($entity->get('field_domain_source')->getValue(), 'target_id');
$domain_source = array_shift($target_ids);
brad.bulger → created an issue.
OK. This may be a duplicate of some existing API issue, I'll keep looking.
Yes, either 📌 Information is missing from the API pages Active is a duplicate of this, or I need to find/create another issue for API, or it's not an API issue (seems unlikely).
I don't know if it is strictly about interfaces. We would have to find a class that extends another class and overwrites a parent class function not defined in the interface. I have done some searching but that's tricky to find.
I don't quite understand what this issue is reporting, but it looks like {@inheritdoc} is not working. Child class method pages don't show the annotations from the parent class method. Is that this issue?
I wondered about that, how would I know which is the case? The copy of the API at api.druphelp.com would imply that the code itself is fine, I'd guess. ContentEntityBase::get() is {@inheritdoc} and the parent is FieldableEntityInterface::get() and that has all of the relevant information. So is this an API module processing bug?
brad.bulger → created an issue.
fwiw, we have a few dozen domains each with their own menu on our site, and we had to change route_param_key to a longblob - some values are over 10K.
I couldn't figure out how to do it, sorry.
brad.bulger → created an issue.
I hope I did that properly, I'm still new to using issue forks instead of patches.
brad.bulger → created an issue.
brad.bulger → created an issue.
I think I know why you had that absolute URL logic in there. In the unpatched code, links to nodes that are tied to other domains with Domain Source show correct URLs to that domain. With the patch, they all come out in the current microsite domain. These are links generated by Linkit in CKEditor 5.
brad.bulger → created an issue.
May be related to this other long standing issue.
brad.bulger → created an issue.
Maybe. That issue seems oriented towards trying to prevent the problem. I am thinking more of how to document it. I am just not sure if there is a way to describe what's happening. Maybe not in 100% of the cases, but would "don't load an entity in this hook" be accurate?
brad.bulger → created an issue.
+1 on adding this. I needed to wrap the included view output in custom HTML that included values from other fields in the outer view, but not if the included view output is empty. The only way to do that is to do the custom HTML in the view field. This patch applied to 1.0.0-beta5 with only some whitespace warnings.
brad.bulger → created an issue.
I'm running Drupal 9.5 (9.5.12-dev ) and Drush 11.7.0-dev. Domain 2.0.x-dev. Still see this behavior.
Can users detect the E_NOTICE from an unserialize() error with an error handler? That wouldn't mean that they are now, of course.
@cmlara I suppose that it is unlikely that the comment would be updated now while a code change that moots it is being considered. That would be the only reason to split the bug off, I think.
The issue is to spell out that any non-string scalar values will be stored as strings. Something like
mixed $value: The value to store. Non-scalar values are serialized automatically. Scalar values are stored as strings.
I don't doubt that this is as designed, the issue is to make it explicit.
Actually using the real service demonstrates this easily:
> $userData = \Drupal::service('user.data');
= Drupal\user\UserData {#9804}
> $userData->set('test', 1, 'testbool', FALSE);
= null
> $userData->set('test', 1, 'testint', 3);
= null
> $userData->set('test', 1, 'testfloat', (10/3));
= null
> $b = $userData->get('test', 1, 'testbool');
= ""
> $i = $userData->get('test', 1, 'testint');
= "3"
> $f = $userData->get('test', 1, 'testfloat');
= "3.3333333333333"
> var_dump(compact('b','i','f'));
array(3) {
'b' =>
string(0) ""
'i' =>
string(1) "3"
'f' =>
string(15) "3.3333333333333"
}
= null
If there are other places where values are handled in the same way, then yes, it would be helpful to note this there as well.
The core form doesn't because it's the whole browser page, so submitting a form gives you the normal feedback of a POST - the spinning wheel of internet delay etc. I get why it seems like a feature request, but I would never give this to my users without something to tell them "yes the form was submitted, please wait".
I wonder if there is some common way that this works for modal popups.
I saw this again in 3.0.x-dev, should I open a new issue?
brad.bulger → created an issue.
I've changed my installed copy to dev-3.x so I had to make a couple small changes to the patch to remove code that was already there. It seems to work fine.
Can someone who understands this paragraph expand it with examples, and confirm that it works as described?
The path type will create a symlink to your local copy. To clone your local copy instead, set the type to vcs. If your local copy does not contain a composer.json file, you must use the package type and set the actual path in the dist part (to symlink) or the Git URL in the source part (to clone).
When it says "set the type to vcs", which type is "the type"? Can we point to any documentation for creating a composer.json file for a module?
I have a local copy of a contributed module. I'm trying to use a package repository entry of type "drupal-module" to get composer to install it into web/modules/contrib/ like a normal contrib module. But there doesn't seem to be any way to get it to make a copy, rather than a symlink.
Not for me. Not clearing the cache with drush, at any rate. And the site does not come up at all to try to clear the cache through the UI. Trying to access /core/rebuild.php does not repair the problem. Running /update.php does repair the problem.