Given the issue title, "won't fix" is the more accurate status. I probably should have changed the commit message in #19 to something else, but oh well.
I'm able to reproduce it now. They key is to set a static image, then refresh the browser page, then link a different field.
I'm not able to reproduce this. Are others seeing this?
I discussed this with @wim leers and @lauriii. Ideally, since beta1 marked the point where we started promising to not break existing site data, we'd get this update path in before RC1. However, this will be the first update path that requires updating content entities, so it might take some time to write it and make sure it works properly, and DrupalCon is starting next week. Meanwhile, the lack of this update path doesn't result in a broken site per se, just some component instances (ones with HTML props) not being editable and needing to be replaced with new instances of the same components, copy the values from the old instance to the new one, and delete the old one. Definitely annoying, but beta1 hasn't been out that long, so not that many sites affected by it, and for the sites that are, it should only require a few minutes of manual effort. Therefore, downgrading to an RC target, meaning a high priority thing to work on after we tag RC if it doesn't make it in before.
Thanks, @tedbow! Per #44, this was tagged as "RC blocker" until we knew what the issues were. Now that we do, I'm downgrading it to "RC target". I think the current MR is great, so if other reviewers agree, let's merge it and make the RC that much better, but if reviewers spot problems with it, we don't need to hold up the RC on it.
To summarize:
- #42.TC03 happens with a Drush delete of the
componententity, not the component's source (Twig file, Block plugin, or js_component entity). I don't think that needs to be RC blocking: people aren't as likely to be deleting the Component entity during component development, they're more likely to be deleting component sources. - #42.TC08 was fixed in #3548922: A component appearing in the list of components to instantiate that is broken during development should convey that → .
- #46 and #51 are fixed by the current MR. Let's merge it if it looks good and not likely to cause other problems.
I think conceptual integrity is very important.
I agree. If I were writing this in spec language, I'd say Content templates SHOULD make use of at least one dynamic prop source, but I hear you that you'd prefer it to be Content templates MUST make use of at least one dynamic prop source
Over a year ago, I argued that an MVP feature for the Content Templates UI should be to visualize which fields have not yet had their data mapped.
I disagree that it's needed for MVP, but I love the idea for that to be added in the future sometime. And I think that would be a very helpful way to guide template builders towards the SHOULD without making it a MUST.
Merged the MR to get the fix into the RC, but back to NW for some kind of test to prevent regression.
I pushed a commit to change it from [] to {}. Rerunning tests.
Would it be possible to add a test to catch this from happening again in the future? Could be a follow up.
Code looks great. Tests pass. #19 confirms it addresses what Drupal CMS needs.
Yay that the fix itself got in for beta2! The update path doesn't need to block RC. In the meantime, people can manually edit and re-save their existing content that uses HTML props that are getting double escaped. Though since we're already past beta, it would be courteous for us to provide the update path relatively soon and certainly before a stable 1.0 release.
📌
Follow-up for #3541037: Improve how list of field suggestions is displayed in the UI for `ContentTemplates`
Active
landed, which was the last issue needed to take Content Templates out from requiring canvas_dev_mode to be enabled to just being an enabled feature out of the box, so in a way, the 1.0 scope of this meta issue is done!!!!
Still keeping this meta issue open for the 2 test coverage issues that are still remaining and to settle on 📌 Require content templates to have at least one dynamic property source Active which @Wim Leers and I are still debating on that issue whether to do it or not.
You already say what the problem is: it's not a template. That's it. So why would we allow it?
I think where we're stuck is that the arguments for allowing it aren't very strong, but neither are the arguments for disallowing it, so it's a judgment call of which set of weak arguments is stronger.
Doesn't that mean you'd still need to pass — at minimum — pass the UUID of the targeted entity into the instance of the code component?
Not for a Page Title block or a JS component that gets the page title from drupalSettings. But perhaps Page Title is a relatively unique exception where we can just expand this issue to include that as well: i.e., dynamic or host-entity-url or page title? But then I wonder how many more things this will end up needing to expand to, and ultimately what's the benefit that's gained from figuring out and implementing that list of things to check for.
As an analogy, we refer to Twig as a templating language and our Twig files as templates, but nowhere do we enforce that every Twig file has to render at least one variable. Are there any good use cases for Twig files that don't use or output any variables? Maybe it's debatable, but would it be more of a benefit or a detriment to stop people from doing that if they want to?
The original MR was merged before beta, but tracking the newly discovered failures in #42 as an RC blocker. We don't necessarily need to fix them before RC, but we should determine what the cause of the errors is and then make a determination based on that whether or not to hold up an RC on fixing them.
While Prop implies component (things that aren't components can have properties, but only components have props), Input does not. So I'd suggest ComponentInputSource.
So I guess one future possibility is if in the future we decide to allow block plugins to opt into Canvas-generated forms (instead of the block plugin's form), in which case we'll be able to use what are currently called PropSource(s) to populate those inputs. So if we want to be forward-thinking towards that future, then yeah, renaming away from the Prop terminology would be good.
"Explicit input" is the generic name for SDC/JS props and Block settings. But the concept of PropSource only applies to the former, not the latter, so I think keeping it as Prop rather than Input would actually be better. Unless we're thinking of a future where prop/input sources can be used to populate inputs that aren't props? But what would be an example of that?
Thanks! Looks great so far, but needs an upgrade path (post_update function?) for existing Component config entities (anywhere else?) unless those are automatically regenerated with this new expression on cache clear.
This also came up in Slack: https://drupal.slack.com/archives/C072JMEPUS1/p1759680539277759. Not just making whether or not the prop is required conditional on another prop, but also making whether the prop (conceptually) exists conditional on another prop.
I think it's up to display builders to implement the UI for this, but I think SDC's need to standardize on how to represent/encode the desired connections. Perhaps we should use json schema's if/then/else syntax for this?
Enum labels are being handled in 📌 Add Support for Defining Labels and Values for List Options in SDC Code Editor Props Tab Active , so should we scope this issue down to just prop machine names?
We definitely don't want people using the |raw filter in Twig to work around this, so tagging as an RC blocker. @larowlan and @Wim Leers have some prior art from a different issue for how to fix this, so assigning to @larowlan because his workday starts sooner. If he can't get to it, we'll make sure that someone else does early this week.
Thanks for reporting this. I added FormAjaxException to the scope of 🐛 Lack of support for EnforcedResponseException breaks form component submission Active which was already in the process of fixing the same problem for EnforcedResponseException. So with that adjustment to that issue, closing this one as a duplicate of that.
Let's add FormAjaxException to this as well. It's the same problem, just the other type of exception that's thrown by FormBuilder. Reported in 🐛 Unable to submit form via Ajax in a Canvas page Active which I'll close as a duplicate.
The challenge in #8 is that this is how Olivero (and any other theme doing something similar) determines what region a block is in:
function olivero_preprocess_block(&$variables): void {
if (!empty($variables['elements']['#id'])) {
/** @var \Drupal\block\BlockInterface $block */
$block = \Drupal::entityTypeManager()
->getStorage('block')
->load($variables['elements']['#id']);
if ($block) {
$region = $block->getRegion();
if ($variables['base_plugin_id'] === 'system_menu_block') {
$variables['content']['#attributes']['region'] = $region;
That last line then allows menu rendering to know what region the menu is in.
However, in Canvas, $variables['elements']['#id'] is the component instance's UUID, which does not correspond to a block config entity, so you don't enter the if ($block) conditional, so the menu then doesn't know its region.
Not yet sure what the best fix for this is. This might also be a slightly different issue than this issue's original title and summary, but I think it's covering the same general territory of the consequences of rendering blocks without the config entity that Block UI normally creates.
Thank you for opening this. It would be great to get this resolved before RC1 or RC2 if we can, so tagging for that.
I think we should go the other way and make sure that when a Canvas field is rendered on the published page, it's rendered without all the theme('field') stuff. The mental model should be that on a Page and on a Content Template (and when we get to it, within exposed slots of nodes), the Canvas defines the entirety of what's being rendered within the "content" region and/or exposed slot.
The use case is to add a CSS class that sets default spacing on all direct children below it
The <body> has a canvas-page class, and the content region has a region--content class, so can you achieve this use case by using .canvas-page .region--content as your selector or prefix?
Since there's what I think is a working MR here, I'm assuming this is "Needs review", not "Active", but please correct the status if I'm wrong about that.
I think #6 is great and we should go with it. If/when anyone wants to design it differently than that, we can open a follow up for further refinement.
This is blocked on 📌 Refine API response with DynamicPropSource suggestions to provide better UX Active .
We have 📌 Follow-up for #3541037: Contextual panel flickers when linking prop to field Active and 📌 Follow-up for #3541037: Improve how list of field suggestions is displayed in the UI for `ContentTemplates` Active as separate individual issues. Is there any other UI polish needed that this issue is helpful for tracking or can we close it?
🐛 500 Error When Editing Code in Custom Code Component under Article Template Active was missing from the issue summary. Adding it.
📌 Refine API response with DynamicPropSource suggestions to provide better UX Active was missing from the issue summary. Adding it because 📌 Follow-up for #3541037: Improve how list of field suggestions is displayed in the UI for `ContentTemplates` Active depends on it.
For easier scanning, moved remaining "must have" issues for 1.0 to the top.
Which presumably means the only way to fetch this information today would be to iterate over all Workspaces, perform a query for each using \Drupal\workspaces\EntityQuery\Query::prepare() to check usage in the latest per-workspace revision?
Does core's Workspaces module allow the same entity to be in more than one workspace? If not, then latestRevision() should be sufficient for at least that. What are the most popular contrib modules that enable multiple branches of forward revisions that we can use for testing the more robust approach?
The MR that implemented what's in this issue's title was already merged in #47. For the follow-up, I opened 🐛 Prevent deleting Code Components if there are usages in forward revisions Needs work , but perhaps an issue summary update here or somewhere is still needed, so I'm setting the status to "Patch (to be ported)" rather than Fixed to indicate that its current scope as indicated in the issue title is done but that this issue still needs housekeeping.
effulgentsia → created an issue. See original summary → .
What's the reason to use a node type instead of the Page entity type for that?
I was under the impression that exposed slots were post 1.0 - is that not the case anymore?
No, that is still the case, so the concern is valid that sites needing exposed slots won't be able to adopt Canvas 1.0 and will need to wait some additional amount of time.
for little gain outside of those using Olivero theme
I think this is misunderstanding what the purpose of this issue was due to an out of date issue summary. The purpose here wasn't to fix a theming mismatch, though that's how this issue was initially opened as, it's that we're not wanting to support/maintain the concept of an individual node using Canvas other than via an exposed slot in the content template.
this severely hamstrings early adopters
You mean between now and when exposed slots are implemented? What are early adopter use cases that you know about where Pages and Content Templates (without exposed slots yet) are insufficient?
A ContentTemplate that is either empty or contains only StaticPropSources no longer is a template for presenting structured data.
I agree with the spirit of this but not the letter. Per #8, you can have a content template that renders structured data from the node, just not via a DynamicPropSource. For example, a Block, such as the PageTitle block or a block that renders some other field from the node, or a JsComponent that does similar via drupalSettings or a json:api request.
I don't think it's pragmatic to try to come up with a way to validate for this broader set of ways of rendering a node's data. But even if it were, we'd have to contend with:
maybe you just want to preview how a static template would look like
And auto-save might not be enough for this. For example, say you're in the process of building a site that you haven't deployed yet, and you're building a View of teasers. During that process you might want to create your Teaser template with only static design elements to start with but you'd want to publish it, so that you can see what it looks like on the Views page.
Beyond the preview use-case, there's also the "quick way to hide content from a published site" use case. For example, say you have a site with a certain node type, like Issues, or Case Studies, or whatever. And for some reason you need to temporarily hide the content from all of those nodes until you resolve whatever problem needs resolving. And maybe you want to customize some message to show instead. One way to do that could be to edit the template for that node type, replace its contents with a static component with a static message, and publish that. Does that mean this isn't technically a template anymore in the purest sense of the term? Yes. But should we stop you from doing this?
As far as whether this as a data integrity issue, it's not like entering "foo" for an integer, or into a reference field where there isn't any "foo" entity to reference. In those cases there's a reasonable expectation of an error being triggered without validation to guard against it. But what reasonable error would we be guarding against if someone publishes a template without anything dynamic in it? Sure, they will have created a "template" that's not a "template" in the normal meaning of the term, but what real problem arises from that?
In summary, I think it's too much trouble to try to validate for "there's something dynamic being rendered" that covers all the ways that dynamic things can be rendered, and there's also some semi-legitimate use cases for creating a purely static "template" even if doing so is counter to the meaning of "template", and there's nothing about how we render templates that we could reasonably envision breaking if nothing dynamic gets rendered, and so for all those reasons, I think this should be "won't fix".
There are very likely zero fields in existing Drupal sites that contain inline-only markup (i.e. with no
,
and other block-level elements). So any such SDC props are unlikely to be able to get populated by structured content.
I think inline HTML props should match to both TextItem and StringItem, just not to TextLongItem or TextWithSummaryItem.
For TextItem matches, I think we'll need to take the ->processed property and run it through an additional strip_tags() that retains only inline HTML. That might mean we need to implement
📌
Allow use of same-shape-adapters ahead of general adapter support in #3464003
Active
first.
CKEditor 5 currently assumes
is supported at minimum
Yeah, we need to either get this fixed upstream or somehow hack around it.
Is the "preview LIES" part of this issue title still accurate? The way I read the comment linked in #3 is that there are situations where you can publish something while it still have invalid values. If those cases still exist, shouldn't those be separate issues? Meanwhile, if you can't publish with invalid values, then what do we mean by the preview lying?
Not every stable blocker needs to block an RC, but this one does.
Not every stable blocker needs to block an RC, but this one does.
Not every stable blocker needs to block an RC, but this one does.
Beta blockers are by definition also stable blockers, but removing the latter tag so as to make it easier to scan a queue of stable blockers that aren't also blockers to beta or RC.
Beta blockers are by definition also stable blockers, but removing the latter tag in order to make it easier to scan a queue of stable blockers that aren't also blockers to beta or RC.
Transferring beta blocker tag from the duplicate issue.
No arguments were made since #20 for keeping this issue open, so marking it Fixed.
#33 doesn't need to block a stable release unless we already know of or suspect a problem.
I think #13 answers #12's question to @lauriii.
And yes, implementing what the issue title now says needs to block the beta1 release, since it's a significant BC break of site data for sites that have already created component trees for individual nodes (articles). We'll need to include release notes that instruct people to manually copy (yay for copy/paste functionality in Canvas!) those component trees from nodes to page entities before they update their site to beta1 (or alphaN if there's an alpha tag that includes this removal prior to the beta1 tag).
wim leers → credited effulgentsia → .
wim leers → credited effulgentsia → .
penyaskito → credited effulgentsia → .
penyaskito → credited effulgentsia → .
penyaskito → credited effulgentsia → .
The sooner we do this, the sooner we get to reap the benefits, but I don't see why we should block a 1.0.0 release on it. Seems like the kind of thing that could non-disruptively go into 1.1.0 or even 1.0.1. Therefore re-tagging from "stable blocker" to "stable target".
I'm all for naming things well. This rename can happen either before or after a stable release.
Per 🌱 Milestone 1.0.0: Production Sites Postponed this is a requirement for an XB 1.0.0 stable release, so tagging it as such.
We can release XB 1.0.0 without this, so switching from "stable blocker" to "stable target".
Within the preview/canvas iframe, global assets are rendered via drupalSettings.xb.globalAssets, which includes jsFooter. Can you clarify steps to reproduce the bug you're seeing?
In fact, since we haven't released the beta yet, we should get this into that as well.
If the hypothesis in the issue summary is accurate, this is a stable blocker, so tagging it as such.
I discussed this issue with @bnjmnm. I believe the correct status of this issue is "duplicate" because per #12.1 it was a symptom of 📌 Redux-aware form input components should be aware of direct element manipulation Active which got fixed.
However, this issue was not the one encountered by the Webform block. Instead, Webform was running into 🐛 Autocomplete machine name handling does not match to machine name Active , which was a symptom of 📌 ComponentSourceInterface::submitConfigurationForm and validateConfigurationForm are never called Active so is correctly marked as a duplicate of that one.
Unrelated to either this issue or to 🐛 Autocomplete machine name handling does not match to machine name Active , there is a remaining bug described in #3523496-40: Block component instance form values not processed by validation/submit handlers → .TC3. @bnjmnm is working on diagnosing that one and will open a new issue for it based on what he learns.
For MySQL itself, it's a bit more vague: https://launchpad.net/ubuntu/noble/+package/mysql-server but de-facto you still get 8.0 it looks like. However I wonder if they're going to switch that mid-release to 8.4 (supported until 2029 according to https://endoflife.date/mysql) as 8.0 goes EOL). So maybe it would be fine to require 8.4 according to #8 if ubuntu installs get updated anyway.
I don't see what's vague in that link. It looks clear cut that Ubuntu 24.04 is on MySQL 8.0. I don't think there's any precedent for Ubuntu to raise the minor version of MySQL (or any other significant package) within an LTS branch that has already been released. Based on all of their track record, I expect Ubuntu to security patch MySQL 8.0 for as long as 24.04 is supported (till 2029 minimum and beyond that for extended support). I think #8 would clearly dictate having Drupal 12 require MySQL 8.0, not 8.4. I don't know if we have consensus on #8, but I'm still in favor of that. Most people are not going to upgrade from Ubuntu 24.04 to 26.04 within the first year of Drupal 12 being out, and while it's true that those people can remain on Drupal 11, I don't think we gain enough from raising the MySQL minimum to 8.4 to be worth the tradeoff in holding back Ubuntu 24.04 users from upgrading to Drupal 12.
Oh! Well that seems like something that's both relatively easy to do and would reduce confusion for beta testers, so tagging it as a beta target, but not a beta blocker.
Closing this as outdated. The Undo and Redo buttons work, and if there are future designs to change their location, new issues can be opened for that then.
Untagging "stable blocker", because XB 1.0.0 does not require a public extensions API. That can come in future minor 1.x releases. The goal of XB 1.0.0 is to get it into people's hands for building and deploying real websites with it, and they don't need to extend the XB UI to do that.
Initially we were only planning to postpone Workspaces to a later 0.x version, but now we're postponing it till after 1.0.0, so re-titling this issue, and we may want to adjust the language in the MR as well.
Where Workspaces will become increasingly crucial is for editing individual nodes within XB, but that's also something we're postponing until after 1.0.0. 1.0.0 will just be for Pages and Content Templates.
I agree in principle that ADRs are valuable and that they're more valuable sooner than later, so I'll try to make time for this when I'm able to, but we're not going to block a stable release on getting this ADR published.
Removing "stable blocker" tag but we'll want to fix this as part of the Content Templates work, so setting the issue parent accordingly.
See #3503038-15: Refactor GeneratedFieldExplicitInputUxComponentSourceBase and FieldForComponentSuggester to need only SDC's ComponentMetadata, not SDC plugin instances → . I'm very much in favor of this issue, but we're trying to pare down the "must haves" for a stable 1.0.0 release in order to unblock a stable Drupal CMS 2.0 release as soon as possible.