Here is a patch as well
nikolaat → created an issue.
nikolaat → created an issue.
Hello. I also reproduced the issue. I don't know why you are arguing about how to reproduce, when it is clear....
The error is saying that you can not pass boolean to write method in the second parameter:
$transformation_storage->write($config_name, $destination_data);
One line above is stored the data of $destination_data
$destination_data = $destination_storage->read($config_name);
When you read what can be returned from read's method annotation:
* @return array|false
* The configuration data stored for the configuration object name. If no
* configuration data exists for the given name, FALSE is returned.
So here it is the issue.....
Changing the status to needs review.
I have added a patch
@sarwan_verma forked the issue and applied the fix.
@sarwan_verma do you tested it? What is your feedback?
NikolaAt → created an issue.
NikolaAt → created an issue.
NikolaAt → changed the visibility of the branch 3405976-mondrake-approach to active.
NikolaAt → changed the visibility of the branch 3405976-transactions to active.
Hello. I recently update this module to latest 1.7.0 version and I noticed this patch.
It is not implemented correctly and might lead to issues.
In my case I am using pluginformalter_form_alter_info_alter so I can dynamically add all taxonomy term form ids. This way if I create new taxonomy, the plugin for form alter will automatically work for it and I limit the risk to forget to include its specific form id.
Here it comes the issue: For you the change is working because you expect that $this->getDefinitions() doesn't return you a result and the validation below doesn't matter. You can not hit it.
In my case $this->getDefinitions() and the following $definitions = $this->findDefinitions() uses my form alter and return a results. This lead me to your change and !isset($definition['paragraph_type']) always return true and it tries to create new instance for something that is not correct.
NikolaAt → created an issue.
NikolaAt → created an issue.
mcdruid → credited NikolaAt → .
NikolaAt → created an issue.
Its strange. If you say so, there is a chance the issue to be reproducible in combination with something else.
But in general I don't think its a bad idea make a validation, before we use something. Which is the patch that I made.
I also had an issue related to this fix. I opened new task and fixed it here: https://www.drupal.org/project/admin_toolbar/issues/3393162 🐛 Base path in admin menu cause error to non admin users. Needs review
NikolaAt → created an issue.
I am able to embed video and see/use it on a page.
NikolaAt → created an issue.
Patch tested on D10.1.2
$element[$key] += [
logic should be inside the else statement otherwise there are errors on node edit page related to empty $default_value.
I've created new branch that is solving issue related to VidyardResourceFetcher constructor and VidyardProvider constructor. It looks like there were changes in the parents.
NikolaAt → made their first commit to this issue’s fork.
NikolaAt → made their first commit to this issue’s fork.
NikolaAt → made their first commit to this issue’s fork.
I am migrating to D10 and I have to handle multiple modules, before the actual upgrade of the core.
Here is a patch based on status_upgrade checks and previous patches here.
It is for 3.0.0-beta1 version.
It is possible to have additional work when the upgrade to D10 is done.
NikolaAt → created an issue.
New version that rely on existing element or initial build of the element is called.
NikolaAt → created an issue.
NikolaAt → created an issue.
Patch compatible with 2.x version
Here it is a patch validating the string value, that is required because of substr()