> If media entity is embedded in textarea directly like this
You need to escape your tags -- we can't see them.
Have you set up the entity_share_embedded_entities enhancer on your fields?
Setting to minor.
With entities such as redirects which don't have a changed field, this just results in an empty column in the pull form.
Might cause log errors on the server though!
I wonder if instead of fixing/changing the Skip Imported processor, we should do this in a new SkipExisting processor.
It would be semantically clearer, and also mean we don't change existing behaviour (even if I do think it's buggy).
Thoughts?
Add details about unpublished entities and entity types with no view permission.
Ah I hadn't thought of using a $ at the end!
In which case, we can maybe close this as not necessary.
Hi!
Thanks for the MR.
If you understand OAuth, could you have a look at fixing the tests too please?
š
AuthenticationOAuthTest is broken
Active
. It would be really great to get those passing so we can be confident in committing this.
Ok, so the question is:
Why do we do
$this->cache[$cid]->expire = $this->time->getRequestTime() - 1;
instead of
unset($this->cache[$cid]);
Is there a performance reason?
The save works -- there is a 'field.storage.entity_test.field_test_text' row in {config} after the save() call.
So it's the attempt to load it during the save of the field config that goes wrong.
Ok so I think the problem is that with a request time of 0, code lines like this in MemoryBackend:
$this->cache[$cid]->expire = $this->time->getRequestTime() - 1;
make the expiry equal to const CACHE_PERMANENT = -1;
But still -- why should incorrectly making cached items permanent cause saving to fail?
The way to reproduce this is by running Drupal\KernelTests\Core\Entity\EntityValidationTest::testEntityChangedConstraintOnConcurrentMultilingualEditing with the MR from š FIx TODO in Drupal\entity_test\Plugin\Field\FieldType\ChangedTestItem Active and with TestMockedTime::$requestTime changed to have a default value of 0.
The only things I can see that call the request time during the config entity save are to do with MemoryBackend.
But surely nothing that happens in a cache backend should influence saving?! If the cache doesn't work properly, then either things aren't cached, or things fail to load from cache. But saving shouldn't be affected!
Doesn't coder have sniffs for documentation problems as well as for code?
Let's see if any other tests are relying on the sleeping field type.
I'm making good progress on this.
I forgot that Functional tests can't mock services from the test -- that's why there is Drupal\update_test\Datetime\TestTime and that needs to stay in a module.
But Kernel tests can and should have a mocking class that can be reused.
- ContentEntityChangedTest and other tests that rely on the ChangedTestItem field type should use this
- ChangedTestItem can be removed
- WorkspacePublisherTest and StageConflictTest have their own mocked time class. Changing those to use the common one that this issue adds should probably be a follow-up
> We are trying to avoid a namespace conflict with an existing contrib module. Claiming the namespace of another existing contrib module doesn't seem to make much sense.
One says it's to be retired, the other does not.
My suggestion about deprecating form classes needs more detail -- I forgot about the twig templates that are involved too! Can twig templates be deprecated?
Thinking about this more, the ternary logic orIf is wrong here.
When we say:
> // The revision log should only be visible to those who can view the
> // revisions OR edit the entity.
what we mean is that if you have access to A, and but not B, then you should be able to see the log message. And in this case, it doesn't matter if access to B is denied by a neutral or a forbidden.
One problem I am having with the new system is that I can't tell whether I am looking at data that is being suggested, that I must save for it to persist, or data that is already saved, and I can save it again to update it. In other words, I never know whether I am looking at a new entity form with default values, or an edit form with existing values.
Good find!!
So do all computed fields from this module show in JSONAPI with this patch?
What's the magic getting needed for?
And also, could you make this a MR please?
BTW my project has asked for āØ add processor for revision author Active as a feature, so I'm adding that as an experimental processor. It can go alongside what gets worked out here.
> I recently discovered that it was possible to pass the hashed password and so it is ok.
The hash salt could be different between different sites.
This needs a rebase.
Also, I'm not sure I like extra functionality going into the EntityReference processor. Maybe we should have a separate user processor?
It's forgotten me again!
Just now, on https://new.drupal.org/contribution-record/11424577
There is a default value for this in the config:
config/install/config_devel.settings.yml
1:auto_import: []
Could you check whether this was set? Was the module installed properly?
One thing to figure out: where should a class used for mocking be placed?
In core/tests/Drupal we have these folders:
BuildTests
FunctionalJavascriptTests
FunctionalTests
KernelTests
Nightwatch
TestSite
TestTools
Tests
One factor I'd not yet considered: some dependencies need the ID existence the other way round!
With an entity reference field, we need the dependency to exist first, so we can point to it.
With a path alias, or a redirect, (see š redirect processor doesn't handle redirects to path aliases Active for example), we need the parent entity to have an ID, because when the alias or redirect is pulled, it needs to get the ID of the thing it's for.
Argggggh.
What I've gone for is a config split setup, which basically has:
- all ES server site config in a config split
- all ES client config in the main config.
Our config split for ES server has this:
module:
basic_auth: 0
edit_uuid: 0 <--- for hacking entity UUIDs when things mess up because path aliases get re-created!
entity_share_server: 0
lbwf_entity_share_server: 0 <-- custom module with tweaks
menu_link_content_view_access: 0 <-- allows access to menu links over JSONAPI
path_alias_view_access: 0 <-- allows access to path aliases over JSONAPI
theme: { }
complete_list:
- system.action.user_add_role_action.content_deployer
- system.action.user_remove_role_action.content_deployer
- user.role.content_deployer <-- user role with all the perms to get entity data over JSONAPI
> One question is there one we want to deprecate here or is that out of scope?
I assumed it was out of scope. Let's ask @catch, who filed the issue.
Needs a rescope.
// If no checkboxes were checked for 'target_bundles', store NULL ("all
// bundles are referenceable") rather than empty array ("no bundle is
// referenceable" - typically happens when all referenceable bundles have
// been deleted).
but:
$form['target_bundles'] = [
'#type' => 'checkboxes',
'#title' => $entity_type->getBundleLabel(),
'#options' => $bundle_options,
'#default_value' => (array) $configuration['target_bundles'],
'#required' => TRUE, <-- it's required
So AFAICT you can't submit the form with nothing checked anyway, and thus the whole of that validation callback can be removed.
I'm no longer able to reproduce this.
Maybe it was fixed as part of refactoring in š revision handling not working when an entity exists already but wasn't imported Active ?
Setting to postponed for now in case it crops up again.
Huh, now it's doing that for me.
But earlier today it wasn't -- I had to set the client about 3 times.
There is also this in EntityTestMulChanged:
public function save() {
// Ensure a new timestamp.
sleep(1);
return parent::save();
}
How much of an impact will this be having on the time our tests take?
There is already a partial Time service for mocking: Drupal\update_test\Datetime\TestTime
It needs to be moved out of that module and into common test fixtures, and expanded to return the mocked value for getCurrentTime().
This also needs hook_jsonapi_entity_filter_access() to be implemented so that the users with the permission can see JSONAPI listings of redirects.
This doesn't seem to be fixed, sorry.
Each time I add a record, it's set to 'Iām volunteering my own time', despite my having saved something else as default previously.
> There are 11 proposed values for the value of that input in here #3542433: Usefull help message or clickable fill for type?, some of them match the values from the "Category" on Drupal.org and some of them don't.
Yup, I saw that issue. Lots of values there don't match to our issue categories.
For this issue here, I think we can just do:
bug issue -> 'fix'
task -> 'chore'
It doesn't sound like that issue is going to change the initial 'fix' / 'feat' part, so why can't this be done independently?
I think there are going to be a lot of commits mistakenly marked as 'feat' that shouldn't be, because people will just take the default!