Account created on 16 August 2007, over 16 years ago
#

Recent comments

πŸ‡©πŸ‡ͺGermany ro-no-lo

Okay, that's life. I debugged this issue for like 4 hours, but find the unsatisfying solution after posting it on drupal.org within 10 minutes.

For anybody run into the same thing: I do have the https://www.drupal.org/project/node_view_permissions β†’ module installed, which I had setup that the current user could not VIEW the first type of entity (see above text). This seem to lead to the awkward problem, that the user can create an entity, but cannot reference it later, because he could not "see" this type of reference. Therefore if he can't see it he propably shall not reference it.

Don't like it, that I have to deal on a coding level with that. But that's what I found.

πŸ‡©πŸ‡ͺGermany ro-no-lo

This seems to be an problem with inline forms module (or so).

πŸ‡©πŸ‡ͺGermany ro-no-lo

I use Vue3 as a JS Frontend. I save the JWT in the local browser storage. For neat relogin on return. The classic Session Cookie is not present. The JWT Token is. Therefore I do have the JWT Token while logged in.

I have no idea if that answered your question. As auth, we use the BEARER on each request.

πŸ‡©πŸ‡ͺGermany ro-no-lo

I checked: when jsonapi_image_styles is uninstalled it works as expected.

I digged a bit deeper.

The ImageStyleNormalizedFieldItemList::computeValue is called in the Validationphase of the FileUpload call, which I don't understand, because, what exactly are you validating there? No idea. Anyways and the same method is called in the serializition Phase, which makes more sense. The thing is even with stepping through the process, I do not understand why it fails, because jsonapi is supposed to anser an fileupload with a json string of the newly created file--file objects.

It bothers me even more, that the upload of the image and the attachment to the entity with the reference seem to work perfectly. Only an EarlyRendererWrapperSomething is bothered and throws an exception. :-(

πŸ‡©πŸ‡ͺGermany ro-no-lo

I had this also. The thing is this: When I upload IMAGES: via the JSON:API process described here: https://www.drupal.org/node/3024331 β†’ it seems that the jsonapi_image_style module creates a `CachableResponse`. which will throw an exception in the file:

File: EarlyRenderingControllerWrapperSubscriber.php

      // If a non-Ajax Response or domain object is returned and it cares about
      // attachments or cacheability, then throw an exception: early rendering
      // is not permitted in that case. It is the developer's responsibility
      // to not use early rendering.
      elseif ($response instanceof AttachmentsInterface || $response instanceof CacheableResponseInterface || $response instanceof CacheableDependencyInterface) {
        throw new \LogicException(sprintf('The controller result claims to be providing relevant cache metadata, but leaked metadata was detected. Ensure you are not rendering content too early. Returned object class: %s.', get_class($response)));
      }
      else {
        // A Response or domain object is returned that does not care about
        // attachments nor cacheability; for instance, a RedirectResponse. It is
        // safe to discard any early rendering metadata.
      }
    }

As info: I have an entity where uploading any type of files is okay. When I upload a Image the error occurs and the CachableResponse has a content of:

{"jsonapi":{"version":"1.0","meta":{}},"data":[{"type":"file--file","id":"c4837397-5e48-41d6-9002-60f68d0e02f5","attributes":{"drupal_internal__fid":721,"langcode":"en","filename":"13.jpeg","uri":{"value":"private:\/\/2024-02\/13_1.jpeg","url":"\/system\/files\/2024-02\/13_1.jpeg?token=nOrLl1pNJflU-H2bVCtDthM6moemK64Q9MDQaN6PRCc&timestamp=1708955605"},"filemime":"image\/jpeg","filesize":8020217,"status":true,"created":"2024-02-26T13:53:25+00:00","changed":"2024-02-26T13:53:25+00:00","image_style_uri":{"avatar":"http:\/\/foobar.local\/system\/files\/styles\/avatar\/private\/2024-02\/13_1.jpeg?token=Rt1fiI8d14VxngMdOnP9r745AXDBhH6VaTcFFckMzIs&timestamp=1708955605&itok=LM9rqf7H","max_650x650":"http:\/\/foobar.local\/system\/files\/styles\/max_650x650\/private\/2024-02\/13_1.jpeg?token=tNO_kBMwcuLRAjt2I9pUX05glzRjdCmK88dC6QVKOhQ&timestamp=1708955605&itok=QYcmOtOQ","thumbnail":"http:\/\/foobar.local\/system\/files\/styles\/thumbnail\/private\/2024-02\/13_1.jpeg?token=l4ViEWtsOLHCRn1G8b3v7NZGhBzZXoPwm_jfys1-OlY&timestamp=1708955605&itok=Oypb40X-","usericon":"http:\/\/foobar.local\/system\/files\/styles\/usericon\/private\/2024-02\/13_1.jpeg?token=szA6cAFC67hB-vPw9zZMvdkhWiX5e4xRBW4DxajFJk0&timestamp=1708955605&itok=SIMJP2lO"}},"relationships":{"uid":{"data":{"type":"user--user","id":"cfecacbc-701e-4bb6-83e3-2a8b15a83fbe","meta":{"drupal_internal__target_id":32}}}}}]}

At least for me, this happens. Uploading 1 or more PDF. No problem. Uploading JPGs: Exception.

πŸ‡©πŸ‡ͺGermany ro-no-lo

As far as I know /user/logout is a POST call. Just saying.

πŸ‡©πŸ‡ͺGermany ro-no-lo

With the latest PHP 8.x I think we could avoid many of these phpDocs by just using the types inside the method signature.

πŸ‡©πŸ‡ͺGermany ro-no-lo

OMG I found a solution. Maybe it is helpful to someone. After Updating to Drupal 10, Drupal lost the *Reference Method* of the Entity. It told me that the selection handler is broken. It could also be, that the uninstall of WMBert as a WIDGET! was the cause. I don't know. Anyways, when I change it to default and pick the correct Entity (storage data) then everything works as expected. (See both screenshots)

πŸ‡©πŸ‡ͺGermany ro-no-lo

Just as a note. If I remove the field from the entity and re-create it with the exact same data AND after that import via SQL the original data into the db. Everything works.

Which leads me to believe that something in the Drupal registry about the storage_data fields is messed up. But because it is Drupal I have no idea where that is and I cannot give advice what to do without deleting and recreating the same data. :-(

To reinterate: I made a Drupal 9 to 10 update prior to this problem.

πŸ‡©πŸ‡ͺGermany ro-no-lo

I checked my other entities which reference to storage_data fields. And ALL have somewhat broken references.

It seems that something at some magic place went wrong, because when I create a second field which references to the same storage_data entities it works finde.

I now have to find a way to fix everything without loosing data.

Btw. no pending update db or entities updates are in queue. Everything is uptodate.

πŸ‡©πŸ‡ͺGermany ro-no-lo

I guess you are right. I thought of a more fundamental design flaw in core. But I take it.

πŸ‡©πŸ‡ͺGermany ro-no-lo

I have no idea why only me has this problem. But something is messed up and I expect the ValidReferenceConstraintValidator.php be part of the problem. I CAN create a storage_data entity, BUT I cannot reference it in another entity. The Validator messes up the valid_entity_ids with the invalid IDs and thus it complains all day long.

πŸ‡©πŸ‡ͺGermany ro-no-lo

There seems to be a deeper problem involved here. Because after updating to D10 I cannot save even entities with referenced storage engine items anymore. It just complains. See screenshot.

πŸ‡©πŸ‡ͺGermany ro-no-lo

Thanks @FMB it worked. I still have no idea, why we need this hook.

πŸ‡©πŸ‡ͺGermany ro-no-lo

For anybody comming here from Google, like me, you can achieve this with the jsonapi_extras module. There is config page "JSON:API Resource overrides" were you can choose to override settings. To do so you choose the entity and click the override button. Then choose the json_raw field of your liking and go to "Advanced" and pick the enhancer "JSON Field".

After that, at least for me, the result of an json_field in the JSON:API was pure JSON.

(I still have to test, if the POST and PATCH will handle the pure JSON as well, but ready pure JSON is a great start)

πŸ‡©πŸ‡ͺGermany ro-no-lo

After a vendor/bin/drush cr the error goes away. At least for me.

πŸ‡©πŸ‡ͺGermany ro-no-lo

Okay, I keept digging and got to the point were the stange condition is added. The TemporaryQueryGuard has a static method called getAccessConditionForKnownSubsets(...) which tests 3 things (if all other access checks were neutral or granted or so). a "published" subset, a "enabled" subset and an "owner" subset. If all 3 of these fail, than it adds the unsovable condition.

Well, as far as I can tell, the "published" check returns neutral the "enabled" is false and the "owner" check returns neutral as well, which leads to the unsolvable condition of profile_id < 1 AND profile_id > 1.

I have - at this point - no idea how I can solve that, to make it usable.

πŸ‡©πŸ‡ͺGermany ro-no-lo

I added an image which shows the point were _somehow_ the applyAccessConditions() method of the TemporaryQueryGuard decides to add the unsolvable condition.

πŸ‡©πŸ‡ͺGermany ro-no-lo

As a test I gave a non-administrator role of that example user (UUID 5) all profiles permissions and removed one by one to find the permission which might be the cause for the unexpected behavior.

When I remove the permission "Administer profiles" the JSON:API result (filter by uid.id) went empty array. But this is of cause problematic, because that permission is correctly labeled as "danger only give trusted users". All other non-administrative permission where still enabled.

This leads me to believe that some permission checks are wrong wired here.

πŸ‡©πŸ‡ͺGermany ro-no-lo

Oh I see that you already did the work, but to be honest I am not *fit* enough to check if your solution will work in all circumstances. I hope the community can help here.

πŸ‡©πŸ‡ͺGermany ro-no-lo

Hi,

thanks for your feedback. I do know that this solution is not optimal. As written in the project description, it was developed with the suggestion of one of the JSON:API core maintainers in mind. Feel free to find a better way.

πŸ‡©πŸ‡ͺGermany ro-no-lo

Hi arti_parmar,

thanks for your time and effort to create the patch. I did it myself, because I noticed your .patch to late. I keeped a few long line warning, but the errors should be gone.

πŸ‡©πŸ‡ͺGermany ro-no-lo

Hi, for everyone coming to this issue after 10+ years, I have created a small Token extension module, were aliased tokens can be used in a programmatically way. It is a different approach, in syntax, but if you are desperate you might give it a try.

https://www.drupal.org/project/token_aliases β†’

(You may have to use it from the git directly.)

Usage:

  $token_service = \Drupal::service('token_aliases');
  $string = 'Hello [user1:username], we have news from [user2:username] see [node:title] and [my_node:title] for more info.';
  // Fully loaded User entities which are keys with the aliases used in the string.
  $data = [
    'user1' => $user1,
    'user2' => $user2,
    'node' => $node,
    'my_node' => $my_node,
  ];
  $result = $token_service->plainReplace($string, $data);
πŸ‡©πŸ‡ͺGermany ro-no-lo

Hi,

I already updated the code to a version 3.x.x because it changed that much, but the Drupal gut system prevents me of signing in or something. It is really frustrating. I might try it again. It was something with a git repo token or so, which was not linking to the position were I can setup that. I do have one for another project here on drupal.org, but somehow the drupalgit is bossing me around for something it misses.

Sorry for that.

Production build https://api.contrib.social 0.62.1