I will point out that my site is on Drupal 10.2.10.
In Drupal 9.5 the PhpSerialize class implements the "SerializationInterface".
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Seri...
This is apparently still the case until Drupal 10.3.x.
For maximum compatibility I recommend implementing my solution.
Ok, here is my patch.
Changing versions does not solve this. There is a problem where the PhpSerialize class is SUPPOSED to be implementing this ObjectAwareSerializationInterface in core but it is not. (ref: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Seri...)
When you actually look at this code in Drupal 10 core.
So instead of accepting THAT particular interface, you can fallback to just the "SerializationInterface" interface. And the reason being is that the new interface extends this interface. So it SHOULD allow for any that inherit from it.
To fix this you need to change this file:
In it add the following use statement at the top:
use Drupal\Component\Serialization\SerializationInterface;
Then change the constructor to say:
/**
* Constructs a StaticCache object.
*
* @param \Drupal\Core\Database\Connection $connection
* The database connection.
* @param \Drupal\Core\Cache\CacheTagsChecksumInterface $checksum_provider
* The cache tags checksum provider.
* @param \Drupal\Component\Serialization\SerializationInterface|int|string|null $serializer
* (optional) The serializer to use.
* @param \Drupal\Component\Datetime\TimeInterface|int|string|null $time
* The time service.
*/
public function __construct(Connection $connection, CacheTagsChecksumInterface $checksum_provider, SerializationInterface $serializer, TimeInterface $time) {
DeprecationHelper::backwardsCompatibleCall(\Drupal::VERSION, '11.0.0',
fn() => parent::__construct($connection, $checksum_provider, 'tome_static', $serializer, $time, self::MAXIMUM_NONE),
fn() => parent::__construct($connection, $checksum_provider, 'tome_static', self::MAXIMUM_NONE)
);
}
I am able to enable the module now AND run the static generator. I will work to create a patch to submit later after I get done dealing with the fire this caused with our failover system.
eelkeblok → credited patrick.thurmond@gmail.com → .
patrick.thurmond@gmail.com → created an issue.
It should be noted that this requires cron jobs to be run to complete. Locally I don't have cron tasks scheduled to run. So I had to do so manually. That should probably be pointed out in the README. Along with the fact that you have to go to "Admin > Reports > Status Report" and scroll down to the "Checked" section to find the status of this.
With that in mind, I did just that with this next patch. Because documentation is good.
Ok, so I ran this and kept running into an error that said "'' not found" (that is two single-quotes). So I created a new version of this to address this with a few additional checks. I tested these checks via the Devel PHP execute module. The error is gone and it populates the arrays it needs to build this queue now (it didn't do that before). Obviously my patch includes the changes from the original patch.
patrick.thurmond@gmail.com → created an issue.
The user needs to know that this belongs in the "extra" parent object.
I'm on version 9.5.9 and unfortunately, that update hook fails for me. Class "BaseFieldDefinition" not found.
The approach in #19 works for me. Except I added the css to a custom module I was already using as a new library. Then used MYMODULE_preprocess_page to attach the CSS.
That said, this overrides the hiding of the controls behind the triple-dot menu, which I think is cleaner. Let me think on this issue.
I'm seeing this problem with embedded form contexts. I have a D9.5.9 site I am working on at the moment. I am using the Gin theme. When I am looking at text area fields using CKEditor that are directly in fields of the content type it looks great (see screenshot below). It clearly stuffs the extra controls behind a triple-dot icon and looks great.
However, when I edit and embedded entity form (entity reference field) and that entity (in this case ECK Brick) has a text area with editor I see it overflowing to the right instead of nesting in this triple-dot menu. That to me is the problem.
Good width display:
Problem toolbar width:
Looks like Drupal 9 DOES support PHP 8.2. And anyway I get this error in PHP 7.4 and 8.1. So that isn't the problem. Why in the world was this deprecation setup without fixing all the places in core first? That seems like an oversight.
It seems to me that this ticket should be about fixing the cause of the deprecation by making all the right changes and not just reporting the issue.
Ugh, I didn't look at the patch file before I uploaded. It lacks all my staged changes. Here is the revised file.
Ok, I have created the validation constraint plugin for this field.
Ok, digging in a bit I think the problem is a two-parter. First, the edit form is never validated. Its results are just blindly saved. Second, the entity class has a function called "getPagesToShowOn()". This function checks for paths that have a leading slash. If it does not find any then it returns an empty array. This sorta acts like validation after the fact.
I can confirm that I see this in the latest version, 2.0.2, and I am having the exact same problem. You can even put in a valid path that just lacks the leading forward slash "/", which is what I did and why it failed for me.
When I do it perfectly, then it operates correctly.
Quick point, if we want to push Vue.js then we need to do more legwork.
According to Webchick → in that React post → :
The issue summary pretty clearly states that the group that's behind React only has bandwidth to pursue pushing React. So folks advocating for other technologies (Vue, Web Components, what have you) would need to present their own research, their own prototypes, etc. alongside. This would be a great thing to do; the more, the merrier; the more data we have, the more sure we can be of the decision. However, Web Components/Vue aren't going to shine by having people behind a different technology trying to cobble something together; the folks really pushing for those will do a much better job, but will need to put in the work.
Later she says this → :
Well, no. This issue is specifically about:
Please keep discussion focused on whether or not React would be a viable solution for Drupal, not the promotion other frameworks.
Specifically in the format of:React does X in this way
It is an issue because YFramework Z is better because it solves the issue in that way.
If you want to merely voice your support for framework X, you can do so at #2645250: [META] Start using reactive declarative JS programming for some new core admin UIs (though it must be said that you're highly unlikely to sway people that way...)
If you want to put forward your support for framework X in the form of a complete proposal that includes detailed research, implementation that can be compared/contrasted against React, etc. you can do that at another issue such as #2913628: Proposal to use Vue.js for building Drupal’s administrative UIsBut this issue is specifically all of the people listed above saying, "We support React as the framework of choice, and furthermore we are all willing to put time/effort into making it happen. If you have reasons why React is not a viable solution, speak now."
It'd be great if we could refocus discussion in this issue on that, because hard data with examples will be a far more effective way of swaying people away from React, if that's your goal.
Anyone want to spearhead this?
We have started using Vue.js heavily here at VML. Specifically on both a D7 and on multiple D8 projects. Our lead JavaScript developer had previously been doing a lot of React development when it was suggested to him that we use Vue.js for the D7 project. He spent a little bit of time learning it and liked what he saw. So he pulled the trigger and started using it for that D7 project.
Since then he has told me numerous times how much better it is to work with Vue.js over React. I, personally, have been doing some Vue.js dev work for these projects and can tell you that it is a powerful, amazing, decoupled JS framework. It has quickly become our goto. We won't even consider React or Angular. Instead we use Vue.js with Vuex immediately.
On top of all of this, from what I have heard from the community, is that devs are draining back away from React faster than they are moving to it. They are finding alternatives to be better, especially Vue.js. Maybe I am misunderstanding things, but usually I have a decent handle on these things. It would be unwise to add a tool (React) that is quickly losing popularity.
Given what I have seen and experienced, I think it would be a huge mistake to use React. Using Vue.js is the right choice and really the only good choice ;).