Paragraphs validation can fail if paragraphs were deleted by a user that was deleted

I would vote to drop them..

The field is also not exposed in the field UI and thus can not be configured for display or so.
And we do not officially support complex Paragraph views so i don't fear there's risk people output this uid field in Paragraph views and we destroy the views.
And we will still implement the interface and can return the host entity uid instead.
So i don't see yet any true promise we break.

While doing those changes to avoid too many storage changes - it would be good to add the missing parent revision reference field as well.
#2949412: Nested paragraphs automatically publish, even if the parent is a draft and child issues...

Just ran into this. I also can't think of any reason why we should record an extra copy of the uid / revision_uid? +1 for removing the fields.

Added this to the #2954487: New Roadmap

Removed the uid, revision_uid fields and changed the related getters and setters.

Added the update function, but when I wanted to uninstall the revision_uid field storage, I got an error, if it had data in the database, so I ended up truncating the both of the fields, just in case. Also fixed the failing test.

Yeah good catch, wouldn't hurt, but it is better this way.

+++ b/src/Entity/Paragraph.php
@@ -242,31 +229,41 @@ class Paragraph extends ContentEntityBase implements ParagraphInterface {
+    return $this->getParentEntity()->get('uid')->entity;
...
+    return $this->getParentEntity()->get('uid')->target_id;

Technically there is a moment when the Paragraph is saved and the parent is not yet set.

You can see the valid state here also:

  public function getParentEntity() {
    if (!isset($this->get('parent_type')->value) || !isset($this->get('parent_id')->value)) {
      return NULL;
    }

Not caring about this case could cause a fatal error in special cases.

Looks like we also need to fix the interface with |null.

Added the checks for the parent entity to the getters. Also added a hook to remove the content_translation_uid from the base field definitions, so if the content_translation module was enabled it doesn't give the user an error that the content_translation_uid field is missing from the database and it won't try to insert data into that column in the future.

This needs a new update number.

+++ b/src/Entity/Paragraph.php
@@ -242,31 +229,49 @@ class Paragraph extends ContentEntityBase implements ParagraphInterface {
+    if ($this->getParentEntity()) {
+      return $this->getParentEntity()->get('uid')->entity;
...
+    if ($this->getParentEntity()) {
+      return $this->getParentEntity()->get('uid')->target_id;

Nitpick, but this always calls getParentEntity twice and there's quite some complexity with it. Let's try to call it only once.

Maybe invert the logic...

$parent = $this->getParentEntity():
if (!$parent) {
  return NULL;
}
return ...

Changed the update number and the parent entity checking.

I noticed some irregularities after using this patch against 8.7.x drupal core. The circumstance is a paragraph fieldset added to a taxonomy vocabulary whereby the paragraph may add taxonomy terms to the same vocabulary.

In this setup the taxonomy term created had no initial referenced paragraph created, and then was initially saved/created without the reference. If the term (with no initial referenced paragraph) is later edited to add a referenced paragraph, clicking on "Add paragraph" results in javascript errors.

AjaxError:
An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /taxonomy/term/525/edit?ajax_form=1
StatusText: 500 Service unavailable (with message)
ResponseText: The website encountered an unexpected error. Please try again later.

The server error log contained this text:

[Sat Dec 22 22:08:56.872819 2018] [fcgid:warn] [pid 5135] [client 127.0.0.1:39598] mod_fcgid: stderr: Uncaught PHP Exception InvalidArgumentException: "Field uid is unknown." at /home/dntgs/docroot/core/lib/Drupal/Core/Entity/ContentEntityBase.php line 587, referer: https://dntgs.local/taxonomy/term/525/edit

The offending code out of ContentEntityBase.php is the following:

  protected function getTranslatedField($name, $langcode) {
    [...]
    // Populate $this->fields to speed-up further look-ups and to keep track of
    // fields objects, possibly holding changes to field values.
    if (!isset($this->fields[$name][$langcode])) {
      $definition = $this->getFieldDefinition($name);
      if (!$definition) {
        throw new \InvalidArgumentException("Field $name is unknown.");
      }

Unfortunately I do not have the expertise to trace the code back to the origin causes, but it appears as though field definitions were changed in the way that owners were fetched by the parent entity? I am not sure if there was some place that was missed in changing the way ownership was set or...

An issue or not?

Removing RTBC in favor of needs work. The reproduction of the issue:

Copy and paste this into a debugParagraphs.make file:

core: 8.x
api: 2
projects:
  drupal:
    download:
      type: git
      url: https://git.drupal.org/project/drupal.git
      branch: 8.7.x
      revision:	b99b499e70929e318d846f5a83628ca01b8ba292
  entity_reference_revisions:
    type: module
    subdir: contrib
    download:
      type: git
      url: https://git.drupal.org/project/entity_reference_revisions.git
      branch: 8.x-1.x
      revision: 167be1c05fb713e030db9c94365d5ef7f09374b9
  paragraphs:
    type: module
    subdir: contrib
    download:
      type: git
      url: https://git.drupal.org/project/paragraphs.git
      branch: 8.x-1.x
      revision: d2eee2d16408bb1d2513dd4db029f67dd3c928dd
#    patch:
#      - "https://www.drupal.org/files/issues/2018-10-15/paragraphs_validation_can_fail-2994286-17.patch"

Then do the following:

$ drush make debugParagraphs.make docroot ; cd docroot ; composer install ; drush si -y standard --account-name='admin' --account-pass='admin' --db-url='mysql://your_user:your_pass/your_database' ; drush en -y field_ui paragraphs

Once the installation has completed:

• First and foremost, create a backup of the database so it can be referenced for easier reproduction of the bug. I did that with mkdir ../database ; drush sql-dump > ../database/debugParagraphs.sql
• Login and go to /admin/structure/paragraphs_type/add and add a new paragraph type.
• Add an entity reference field on it to the "tags" vocabulary (automatically created in the "standard" installation), save.
• Then go to /admin/structure/types/manage/article/fields and add a field referencing the paragraph just created.
• Then go to /admin/structure/taxonomy/manage/tags/overview/fields and add a similar field referencing the exact same paragraph.
• Then go back to the commandline and drush cex -y (My "sites" folder is outside the docroot, and are automatically re-linked when I run a custom drush script to rebuild the code of the site.)

Once the backup of the database is made, and the sites directory is out of the docroot and symlinked, it makes recreation of the bug easy.

Afterward, I reimported the initial database and imported the configuration changes, I went and created an article using a Test Tag in the paragraphs field. Afterward, I went to /taxonomy/term/1/edit and added a new paragraph option with another tag. Worked like a charm.

Then I went and uncommented the "patch" line and the patch itself in the debugParagraphs.make and rebuilt the code base. Then I reimported the initial database and the configuration that was saved. I repeated the process above and was unable to add another tag in the paragraph field after going to /taxonomy/term/1/edit because it threw errors similar to the ones outlined in the previous comment.

Hopefully, this sheds a bit more light on where the errors are coming from?

Is this what people are after?

The website encountered an unexpected error. Please try again later.InvalidArgumentException: Field uid is unknown. in Drupal\Core\Entity\ContentEntityBase->getTranslatedField() (line 587 of core/lib/Drupal/Core/Entity/ContentEntityBase.php).

Drupal\Core\Entity\ContentEntityBase->get('uid') (Line: 253)
Drupal\paragraphs\Entity\Paragraph->getOwnerId() (Line: 110)
Drupal\Core\Field\Plugin\Field\FieldWidget\EntityReferenceAutocompleteWidget->formElement(Object, 0, Array, Array, Object) (Line: 335)
Drupal\Core\Field\WidgetBase->formSingleElement(Object, 0, Array, Array, Object) (Line: 202)
Drupal\Core\Field\WidgetBase->formMultipleElements(Object, Array, Object) (Line: 104)
Drupal\Core\Field\WidgetBase->form(Object, Array, Object) (Line: 171)
Drupal\Core\Entity\Entity\EntityFormDisplay->buildForm(Object, Array, Object) (Line: 650)
Drupal\paragraphs\Plugin\Field\FieldWidget\InlineParagraphsWidget->formElement(Object, 0, Array, Array, Object) (Line: 335)
Drupal\Core\Field\WidgetBase->formSingleElement(Object, 0, Array, Array, Object) (Line: 831)
Drupal\paragraphs\Plugin\Field\FieldWidget\InlineParagraphsWidget->formMultipleElements(Object, Array, Object) (Line: 104)
Drupal\Core\Field\WidgetBase->form(Object, Array, Object, NULL) (Line: 942)
Drupal\paragraphs\Plugin\Field\FieldWidget\InlineParagraphsWidget->form(Object, Array, Object) (Line: 171)
Drupal\Core\Entity\Entity\EntityFormDisplay->buildForm(Object, Array, Object) (Line: 125)
Drupal\Core\Entity\ContentEntityForm->form(Array, Object) (Line: 94)
Drupal\taxonomy\TermForm->form(Array, Object) (Line: 117)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 518)
Drupal\Core\Form\FormBuilder->retrieveForm('taxonomy_term_tags_form', Object) (Line: 275)
Drupal\Core\Form\FormBuilder->buildForm('taxonomy_term_tags_form', Object) (Line: 93)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 669)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

We need one more update function. Working on that.

We needed to update the metadata keys too. :)

This is needed, thanks @Berdir.

Tests will be fixed here #3026890: Update to Entity Browser 8.x-2.x in tests

I was subscribed to this issue.

+++ b/paragraphs.install
@@ -255,3 +255,46 @@ function paragraphs_update_8015() {
+    if (is_array($metadata_keys) && isset($revision_metadata_keys['revision_uid'])) {

I think isset($revision_metadata_keys['revision_uid']) should be isset($metadata_keys['revision_uid']).

Sure, I think this should address both comments above. Thanks for noticing. :)

This is making Lingotek tests fail, I'm still looking at the reason.

So actually fails when calling getOwner in embedded paragraphs. We cannot assume there is an "uid" field.
This is not ideal, but at least better and works for me.

Simplifying this by @Berdir suggestion on Slack.

Awesome, thanks!

How could I see this error with paragraphs version 8.x-1.6?

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision.revision_uid' in 'field list':
SELECT
 revision.revision_id AS revision_id,
 revision.langcode AS langcode,
 revision.revision_uid AS revision_uid,
 revision.revision_default AS revision_default,
 base.id AS id,
 base.type AS type,
 base.uuid AS uuid,
 CASE base.revision_id WHEN revision.revision_id THEN 1 ELSE 0 END AS isDefaultRevision
FROM
{paragraphs_item} base
INNER JOIN {paragraphs_item_revision} revision ON revision.revision_id = base.revision_id
WHERE base.id IN (:db_condition_placeholder_0); Array
(
    [:db_condition_placeholder_0] => 14
)
",

I see. I was on the dev version, run these updates, then switched to 1.6.
Switching back to dev..

Thanks

I'm having issues with this patch/Paragraphs 1.7/1.8 - I can't delete paragraph fields with content anymore! See #3044256: Unable to delete paragraph fields without error