#2602662: Feed ID should be required base field for aggregator items made the 'Source feed' required for aggregator items, but the update function was untested and did not actually update the field.
Provide a new update function and test it.
Review.
Nope.
Nope.
Nope.
EntityListBuilder currently just renders the entity operations as the only part of the row. This is not very useful as is, so it always needs to be extended. In the most trivial case, which is implemented several times in core, it is extended just to display a label in each row in front of the operations. This is cumbersome and makes the out-of-the-box experience for new entity types less than ideal.
Make EntityListBuilder render a label for each render in case the entity type provides a label key. That way EntityListBuilder can be used as is in core but also for contrib and custom entity types which do not need anything fancy.
As a second step we could consider making the label a link to the entity view page, but let's do that in a follow-up as that is non-trivial in its own right.
| Issue category | Because this increases the maintainability of Drupal because it actually removes code this is not a feature request but a task |
|---|---|
| Issue priority | Normal because nothing is broken as is, even though the DX is less than ideal |
| Disruption | Disruptive for core/contributed and custom modules that extend the default EntityListBuilder because a label will automatically be added. In most cases, they will have added the label manually anyway, and they will have used the same key that EntityListBuilder uses so they will not be affected, but in some cases this could lead to the label being displayed twice. |
Steps to reproduce:
$entity->getTranslation("second_langcode");$clone = clone $entity$entity->field_name === $clone->field_name. Changing field values in $clone now also changes the values in $entity which precisely breaks the contract of the clone operation.This affects content entity forms because during validation a clone of the entity is populated with the user submitted values to perform $cloned_entity->validate(). Due to this bug, after Ajax operations in content entity forms, the values in $this->entity during subsequent form building are actually the updated values from the user input and not the original entity values.
When there are at least three languages and a node has been created and translated into one language (but not the other(s)), it is possible to change the language of the original node to the language(s) in which no translation exist(s) yet. Due to the above problem this means that $this->entity->language() returns the previously selected language after Ajax requests - which may differ from the original entity language.
ContentEntityForm::updateFormLangcode() is run as an #entity_builder, so that $form_state->getLangcode() will return the previously selected language after Ajax requests. The fact that an #entity_builder has side effects is problematic, as discussed in #2799637: Document that #entity_builders and overrides of EntityForm::copyFormValuesToEntity() must be idempotent. In this concrete case, however, the problem is masked, because due to the bug described above, $form_state->getFormObject()->getEntity()->language()->getId() and $form_state->getFormLangcode() always return the same thing.
Thus, fixing the clone bug leads to the case where the language of the entity and the form langcode are different: The language of the entity is no longer (inadvertently) updated, but the form langcode is still updated by the #entity_builder. This breaks an expectation in the Paragraphs module.
Ensure the fields array is actually cloned by overwriting the original reference with one pointing to a copy of the array.
The original solution of only fixing the cloning discovered another bug and it is that when cloning properly then the form will be rebuild with the original entity instead of the modified one (which has been caused by the wrongly cloning). The problem relies in the entity builder ContentEntityForm::updateFormLangcode which is not idempotent and will change the langcode stored in the form state storage each time an ajax call is triggered and the user has changed the language in the language widget when ContentEntityForm::validate is executed and the entity build for validation with the user submitted values. So what we have now is that we are not setting $this->entity generated based on the user input on ajax calls but we are updating the form state langcode based on this intermediate entity which we are throwing away. Setting $this->entity is impossible as #2811841: Add test coverage ensuring user input is mapped on the correct form elements when elements are reordered currently shows.
We have currently two approaches which we are discussing:
1. Do not use the entity builder ContentEntityForm::updateFormLangcode as it is not idempotent, leave the function there and mark it as deprecated as of Drupal 9.0.0. This approach assumes as we are not setting $this->entity and rebuilding the form with the original entity that the form language is still the original one and if some code used to rely on changing the language in the form state the new language from the language widget has to be retrieved using $form_state->getValue($entity->getEntityType()->getKey("langcode")). This approach solves all the provided tests.
2. Always update the form state language code even if not setting $this->entity and continue using the entity builder ContentEntityForm::updateFormLangcode. This approach still has the problem that the title of the page will suddenly be changed by the content_translation module, as on form rebuild the decision would be made that a translation is being edited and [%translatio% translation] will be added to the page title. Additionally during form rebuild the form alter hooks which generated the first form send to the user now will be called with a form state indicating a different language than the one of the entity used now for rebuilding the form.
Review.
none.
none.
none.
Currently we set $entity->original during the saving process however the entity object does not have such a property and therefor on content entities the magic methods __isset, __get and __set will be involved. In order to make the original property official and do not involve the magic methods it makes sense to create a property on the entity object for it.
Create a property $original on \Drupal\Core\Entity\Entity.
Review & Commit.
None.
None.
None.
As discovered by acbramley in #2700197: Transition Event $state_before is not correct when transitioning a non default revision for Workbench Moderation, $entity->original (as found in hook_entity_presave and similar) is not, in fact, the original entity. It is the current default revision. In core, under normal circumstances, that is always the same as the original entity. However, there is nothing that guarantees it is. In fact, if you install Workbench Moderation (or any other module that makes use of forward revisions), it will very often NOT be the case. That results in $entity->original being wrong in many cases.
On further investigation, I believe the issue is in EntityStorageBase::loadUnchanged(), which does a fresh load from the database(!) using ::load(), which by design looks for the default revision only. What we need instead is a loadLatestRevision() method, which will load the latest revision regardless of what it's default status is.
In Workbench Moderation, I have this routine for doing so:
public function getLatestRevision($entity_type_id, $entity_id) {
if ($latest_revision_id = $this->getLatestRevisionId($entity_type_id, $entity_id)) {
return $this->entityTypeManager->getStorage($entity_type_id)->loadRevision($latest_revision_id);
}
}
public function getLatestRevisionId($entity_type_id, $entity_id) {
if ($storage = $this->entityTypeManager->getStorage($entity_type_id)) {
$revision_ids = $storage->getQuery()
->allRevisions()
->condition($this->entityTypeManager->getDefinition($entity_type_id)->getKey('id'), $entity_id)
->sort($this->entityTypeManager->getDefinition($entity_type_id)->getKey('revision'), 'DESC')
->range(0, 1)
->execute();
if ($revision_ids) {
$revision_id = array_keys($revision_ids)[0];
return $revision_id;
}
}
}Which I don't really like, but it's the best I could do from the outside. We could move that logic, more or less, into EntityStorageBase, and then use getLatestRevision() instead of loadUnchanged() (which maybe should be deprecated, per #2226037: Change signature of Entity::loadUnchanged() to accept an EntityInterface instead of random ID). I'm not sure what the entity cache implications are of this approach, however.
Alternatively, I'm open to suggestions for alternate implementations from the Entity API maintainers. :-) As long as in the end we end up with a useful getLatestRevision() method, which we then call from EntityStorageBase::doPresSave() and others, that would fix the bug as well as let me remove some now-redundant code from Workbench Moderation, which would be a nice bonus.
Confirm that the above is the best approach, then implement it. (I can do the latter if a maintainer can do the former.)
None.
New API method, maybe.
Over in #2335879: Change SqlContentEntityStorageSchema::requiresEntityDataMigration() to ask the old storage handler if it has data rather than assuming yes unless NULL storage we've marked the QueryFactory class as final and added comments that it should not be overridden. We can remove this service entirely and just use the entity storage's getQuery method.
Notice: Trying to get property of non-object in Drupal\Core\Entity\RevisionableContentEntityBase->getRevisionLogMessage() (line 104 of /vagrant/app/core/lib/Drupal/Core/Entity/RevisionLogEntityTrait.php)
Return an empty string for missing log messages as per the interface:
/**
* Returns the entity revision log message.
*
* @return string
* The revision log message.
*/As a followup of https://www.drupal.org/node/2669802. We noticed that most forms extending ContentEntityForm implement the things below (and not all in the same way). It might be good to standardize this a bit more in ContentEntityForm. This means less logic for people implementing it.
Form():
Save():
Maybe some more?
Problem
When creating a new form (through Contact Forms), the user can define the form display and view display. Both are working fine when viewing a form or a submission (using the Contact Messages module). However, when the visitor clicks on preview before submitting, the preview shows the individual form field values in an apparently random order.
Inspecting the HTML, it seems, all previewed fields are sorted by their machine name. I am not sure, how the preview is built, in MessageForm.php it says$form['preview']['message'] = $this->entityManager->getViewBuilder('contact_message')->view($message, 'full');
but I can't find the correct implementation of that function to take a look.
I think, the correct viewBuilder is in the Contact Storage module which is currently Third-Party but seems to be on its way to become part of Drupal 8.3.x (see #2750629: Add view builder for contact module's Message entity). Then I get lost where to look next in order to change the sorting to use weights.
I get this error when adding a translation. The URL may than node/2/translations/add/de/en:
InvalidArgumentException: Invalid translation language (en) specified. in Drupal\Core\Entity\ContentEntityBase->addTranslation() (line 691 of core\lib\Drupal\Core\Entity\ContentEntityBase.php).
I have created an English translation of a German article. I also get Article English article 2 has been updated. For repro you need to uncheck Create new revision in the node and translation.
I have a question about the 8.3 Content Moderation module. In pre-8.3 Content Moderation, you can edit the machine names of the states because you can have duplicate state labels. In the 8.3 version (interactive demo), I didn't see the means by which you can edit the state's machine name when you add a state. Will we be able to have duplicate state labels? If so, we'll need the ability to change the state's machine name. This is important, because I need the ability to create a new draft of a published item, as well as un-publish a published item and put it back to a draft state. I don't want to archive it - archive has a very different business meaning from un-publishing something that was published erroneously. In order to accomplish that, I would have 2 different Draft states - one is the default revision, the other is not. But I want both to have a label of Draft. I voiced this concern in the original issue in which this new version was documented. My comment was #65:HERE
Thanks!
The Composer autoloading function fail when classmap is not defined
Script Drupal\Core\Composer\Composer::preAutoloadDump handling the pre-autoload-dump event terminated with an exception
[ErrorException]
Undefined index: classmap
When I am trying to translate the menu item under main menu e.g "About US" its show the message like You are not authorised to access this page. I have checked all the permissions to the admin account. And also select the multilingual option "translate and localize" but same error occur. I don't know where i can troubleshoot this error.
For three content entity types (menu_link_content, shortcut and taxonomy_term), in respective overview form, the operation list is hardcoded (e.g. core/modules/taxonomy/src/Form/OverviewTerms.php:269).
If I add a new operation via the hook_entity_operation, the new operation don't appear in the list.
Take taxonomy_term as an example:
Define the new operation
function mymodule_entity_operation(EntityInterface $entity) {
if ($entity->getEntityTypeId() == 'taxonomy_term'&& $entity->hasLinkTemplate('mymodule-link')) {
return ['my_operation' => ['title' => t('My operation'),'weight' => 50,'url' => $entity->toUrl('mymodule-link'),
],
];
}The new operation don't appear in the list /admin/structure/taxonomy/manage/{taxonomy_vocabulary}/overview
For me, each entity could provide his operation list.
I would add (like linkTemplate):
setOperation() to add operations and getOperations() to retrieve all operations defined for the entity typeoperations() the get the operation list for one entityDiscuss
Writing the patch
Entity operations for terms are hardcoded in taxonomy terms's overview page; add or alter operations is impossible.
Introduce a taxonomy term list builder that provides the operations and invokes all existing hooks for other modules to alter the operations or provide custom ones. See #3 and #4 for why we need a list builder.
Make a patch.
none.
none.
| Issue category | Bug |
|---|---|
| Issue priority | Normal, because no data loss or seriously broken features. |
Entity operations for menu items are hard coded in the edit menu form; add or alter operations are impossible.
Introduce a menu link list builder that provides the operations and invokes all existing hooks for other modules to alter the operations or provide custom ones. Update the menu plugins to provide relevant links.
Get proper translate route for content links.
none.
none.
I have just installed Drupal 8.1.5, I am logged in as Administrator (User 1) and created a few content pages and enabled the Update Manager module
When I tried to install a new theme there is no install link on the theme administration page and on visiting admin/appearance/install it throws access denied page..
The same happens while trying to run cron... but Modules can be easily installed..
Any help.. or should I give a try to some earlier versions .. say 8.1.3
Thanks..
This module is much needed. I hope the module will move to core someday soon.
I have a multiple language website in English, Spanish and Chinese. Each of the languages has a separate primary menu. This is done as core does not currently support menu translation. Each of the three primary menus create a block that is only visible for the language of the menu. All this is working well.
I would like to use this module to add an attribute class to two menu links in each of the three menus. The css associated with the attribute class makes the menu links bold.
I installed this module. I added the attribute class to two links in our English primary menu. The two menu links became bold -- all good.
I added the attribute class to our Chinese menu. The two links were removed from the Chinese menu and stored in the English menu. The attribute class was added to the menu links but are displayed as part of the English menu -- in random places of the menu tree. This leads me to the conclusion that the current code does not handle the situation where there are multiple primary menus.
It would be great if this module would save the menu id on fetch/display and use the same menu id when the menu link is stored -- back into the menu where it was fetched.
In past few months (since Dublin) we reached the agreement to bring the contributed Media Entity module to core (under the name Media), which will allow us to implement better and more powerful media handling.
For more info see #2801277: [META] Support remote media assets as first-class citizens by adding Media Entity module in core, #2825215: Media initiative: Essentials - first round of improvements in core and #2786785: Media in Drupal 8 Initiative.
This is blocker for all issues that we'll be focusing on at Media sprint in Berlin (starts on December 12th 2016). Marking as major for that reason.
Bring Media entity module in core mostly as it is. Any changes made will need upgrade paths for the existing module users.
Remove integrations with few contrib modules: Inline entity form, Devel Generate and Plugin. We will open follow-up issues in those modules after this lands.
A special branch is maintained in the Media entity module with this changes and will be rebased against 8.x-1.x regularly.
Media entity is stable and extensively used and there are no urgent changes planned for it. Other steps, which will happen after and not directly change Media entity are explained in #2801277: [META] Support remote media assets as first-class citizens by adding Media Entity module in core.
Adds new fieldable and revisionable entity type.
#2831936: Add "File" media type plugin and #2831937: Add "Image" media type plugin and #2831944: Implement media type plugin for remote video to provide media type plugins. These are planned to live in the same module.
#2834729: Create an MVP for adding and re-using Media which would possibly live in a different (experimental) module.
Less significant ones directly related to this issue. Need to identify which ones are requirement for Media to land stable.
When #2831274: Bring Media entity module to core as Media module lands we'll have Media entity in core. But it won't be of much use if we don't provide any proper media plugins.
In order to replicate current file field behavior we need support for local documents/files.
Adopt documentfile plugin from Media entity document contributed module.
Besides that create a media bundle for documents files with sane default configuration. Location of this bundles still needs to be decided as it could be in module that provides media entity, (experimental) module that implements media library (see: #2796001: [prototype] Create design for a Media Library), in standard or in an experimental profile.
- Adopt document file media type plugin handler
- decide where media bundles types will be defined
- create media bundle handler for documents