🇺🇸United States @cosmicdreams

@simohell I'll have to manually test this. The background color of "Canvas" appears to be defaulted to a dark color. I worried this would be continuance of the issue I'm seeing where this color makes it difficult to see dark text when the body doesn't define a background color. The choice of white was to give a color similar to the Body's default color.

smustgrave → credited cosmicdreams → .

Yea, That's what I've been observing, Since SB8. I'll see if I can update the README

A recent fix addresses this issue. See: ✨ After closing the preview by clicking the X the preview should not open again until I click Preview Active

No sorry. I mainly have seen this when I'm using the same page preview on projects. When a site builds a custom theme and they aren't establishing a base color, then the off-canvas dialog's dark color make an outsized impact on how the preview appears.

I think, if you were to hack olivero to remove all of it's background color from body / html / * you would see it.

It does appear that we need to ensure that the preview is hiding the new navigation bar.

It is strange that we have to exert an extra effort to ensure this is not seen. I wonder if an effort was put forth to make sure the navigation bar is hidden in Node's preview. That seems like the best place to look first.

In regard to the usability concerns of having the preview load for mobile users, we have the same support that Drupal core provides for the off-canvas dialog. This means that a user can not preview and edit at the same time. I think we are still providing value by reducing the time it takes to see the preview though. I don't think there's anything to improve (for your second point). Would be happy to hear of any improvements you can suggest though.

Ah yes. Very good. Great improvement.

We've already applied this fix.

I think..... Maybe we've already applied the fix that is in #11. Well, most of it. We aren't (in code) defaulting the display to the 'full' display mode. But doing so might be dangerous because it is possible to get rid of the 'full' display mode. So hard coding that feels dangerous.

Can you retest? Is this still an issue?

I put together a demo video to show that I'm not seeing this issue. (Drupal 11, PHP 8.3). Maybe just writing a response here would be sufficient.

The preview updates when you make a change in a field and then change the focus of the field to something else. This allows you to make a lot of edits in a field like an autocomplete field and then only get the preview to update when you are done. I think we may be confusing users by having the title field live update, because that's the only field that does live update.

Every other field only updates when you change your focus to another field or anything else. Like make your change to the autocomplete then tab away.

For the Umami demo profile, the autocomplete field is the last field of the article content type. Maybe that is why it's easier to see the issue with this autocomplete field, because what are you going to tab to?

Until we have a reason to fully adopt a live-preview strategy for all fields, I'm marking this issue as works as designed.

@scott_euser would it be alright to bounce this edit back to you. The fix is the same in principal. But I felt it was important to get the order of injected objects to be the same as what I'm seeing in core.

cosmicdreams → changed the visibility of the branch 3485682-off-canvas-dialog to active.

cosmicdreams → changed the visibility of the branch 3485682-off-canvas-dialog to hidden.

cosmicdreams → created an issue.

Hiya Scott. This issue has a high priority for me. I'll be getting some time to fix it next week it seems.

cosmicdreams → created an issue.

cosmicdreams → created an issue.

cosmicdreams → created an issue.

Ah yes, incomplete data.

When we think about auto save, data that is incomplete and would fail validation, are solutions that persist data on the frontend able to be a candidate solution.

I'm not familiar with yjs or other solutions of that class. But even something as simple as JavaScript's local storage might provide a means to store complex data temporarily

Storage API
Indexed DB
And React is in the mix so, I guess Redux

All provide various advantages / use cases.

Do we have to auto save to the backend? Is there no way we could solve this on the frontend?

Same Page Preview reuses NodePreviewController's method of using TempStore to persist the FormState of an unsaved node.

What's being discussed here appears to be decision to use workspaces and revisions instead of tempstore when building something with Experience Builder. Is presume the "something" here will be stored as an entity somehow, but maybe that something isn't node.

My question is, when we consider nodes, are we talking about modifying the underlying mechanism for storing unsaved nodes, so that they are previewed?

Also, when previewing nodes, is there the possibility of reusing Experience Builder's preview capabilities? In the XB future, does thinking about content as nodes even matter anymore?

My next workspace adventure will focus on giving workspaces_parallel a try. My focus needed to shift to End-of-Month / Start-of-Month work. Which in part means supporting a content team as they use a solution that leverages cloning entities for a content push. After the push is over, I'll have a window of opportunity to demo a solution that uses workspaces / workspaces_parallel as an alternative to what we're currently doing.

Thanks catch that does sound like it would work. I want to focus in on side thought you brought up:

not sure what a good UX for it would look like.

What I can see as good UX for this is to not provide a new UX. Simply remove the constraint for editing content that is also in a Workspace. Allow content to diverge. And then when it comes time for conflict resolution, default to "force push" logic. Which would mean the last revision saved is the new revision.

Since that seems like the obvious choice, and was likely considered, I'm pretty sure there are problems with that approach I'm not thinking of. Otherwise, why not just do this?

In addition, please consider http://dgo.re/workspace_parallel to be included in your plans.

cosmicdreams → created an issue.

griffynh → credited cosmicdreams → .

My theory was that the duplication test needed the same steps / structure as the delete test. But waiting for the preview to be ready did not fix the test.

I'm left wondering if the component duplication logic is what is not working.

I've added the code change I was talking about in the Gitlab discussion. I wonder, does pressing 'Command + D' actually duplicate the element?

The next test fails to measure that there are two elements present where there was once one. It times out. Is it stalling because it's trying to look for the duplicate but it's not there yet?

cosmicdreams → made their first commit to this issue’s fork.

#4 I am referring to the empty slots.

Sorry @wim leers I just know saw you asked me that.

And I think I see the root cause. Simple XML Sitemap PHP extensions reports that the xmlwriter PHP extension is not enabled.

I'm not sure if I've assigned this ticket to the right place as this is a Starshot specific concern.

Bah: looks like I see the error on more pages. Not just trash's admin pages.

redirecting.

cosmicdreams → created an issue.

Hi @tonypaulbarker, one thing I would love to have is a greater integration of svgs within CKEditor. I've created a ticket here to describe my use case : https://www.drupal.org/project/svg_image_field/issues/3476305 🐛 SVG (NOT IMAGE) field Active

I am unsure what the next step is, but am working on a new ckeditor plugin to inject svg into the source.

Is this issue still valid? It's from 2022 and workspaces are in core now. A lot has changed.

If workspaces do still have an issue with entity_reference_revisions then that would have a large impact and deter folks from trying it.

@deepakkm Did you accidentally include work from another issue into mine?

Test passes, ready for review.

Thanks for the review. I can see now that even though I can't get these tests to run locally (i'm on a Mac and xQuartz isn't working properly) I do see the test results on Gitlab. I see my use of data attributes is what is at fault here. I'm attempting to provide a more Cypress-centric implementation now.

Also, I can't seem to be able to run any tests in my local development environment. I'm working through that.

I'll take a shot at writing the test, but this will be my first one for Experience Builder. Are we talking about a cypress test?

In general, the dropzone for the slot is relatively small / short? Are we opposed to making the dropzone taller (have more height)?

I really like the solution of using method="dialog". Sounds like it was custom made for this situation. I'll check what I pushed recently and make sure I work this in.

I've included the recommended changes from #7.

cosmicdreams → created an issue.

I did consider taking over the form's submit event. For now, I'm testing with only taking over the form's KeyDown event. In my local testing that has proven to be sufficient. I'm in the process of getting the tests to run to see if this is ready for review.

Went down the road of pursuing a backend solution. Setting the action of the form to an empty string

ComponentPropsForm::buildForm

public function buildForm(array $form, FormStateInterface $form_state, ?FieldableEntityInterface $entity = NULL): array {
...
# Remove the action attributes value to prevent the form from being
    # submitted when user presses Enter.
    $form['#action'] = '';
    return $form;
}

This did what was intended and now pressing enter doesn't directly lead to an error page. But hitting enter still "submits" the form which leads to a moment where the page reloads. After the page reloads, all my components I've placed are gone, and I have to start over.

I don't think this solution is enough. Perhaps it does ultimatley make sense to remove the giant value in the action attribute, but it still is a bug to users.

I think we should pursue a solution where we teach the component props form to respond differently to pressing Enter. Perhaps that's not sufficient to fix the bug, because the main thing we want to avoid is doing a full form submission.

The main thing to figure how is where to make change. These two Form objects seem like good candidates:
* ui/src/components/form/Form.tsx
* ui/src/components/form/FormElement.tsx

cosmicdreams → created an issue.

Very interesting...

Is this an effort to make it easier to create components? https://developer.stackblitz.com/guides/user-guide/what-is-stackblitz

I've attempted to contribute that change. I was getting errors initially that I didn't have permission to push this change. But I think I worked around that.

cosmicdreams → created an issue.

It certainly is nice to have really good looking components to use while demonstrating why this is an interesting thing to new eyes.

In this time when we are in between, with some people using an older version of drush and some using the newest, perhaps we should provide both commands and document what versions they are compatible with.

I can go through the documentation pages and make the changes myself if that helps.

In my view, the cache clear was needed.

Give it a go, maybe the issue is just a me thing

cosmicdreams → created an issue.

Modify ddev setup config to include an explicitly set version of node.

As I noted in Slack, we should probably include this to the ddev setup step

ddev config --nodejs-version=21

minneapolisdan → credited cosmicdreams → .

minneapolisdan → credited cosmicdreams → .

I think this patch needs more testing. I did the following:

1. I rolled a brand new D11 site with just features (and the require dependency, config_update and features_ui, installed).
2. I navigated to the features_ui admin page (/admin/config/development/features) and received the following error:

The website encountered an unexpected error. Try again later.

Error: Call to a member function getName() on null in Drupal\features_ui\Form\FeaturesExportForm->buildPackageDetail() (line 382 of modules/contrib/features/modules/features_ui/src/Form/FeaturesExportForm.php).
Drupal\features_ui\Form\FeaturesExportForm->buildListing() (Line: 181)
Drupal\features_ui\Form\FeaturesExportForm->buildForm()
call_user_func_array() (Line: 528)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 279)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Came across this patch because I wanted to work features into a demo. I can't even get the demo going because I can't get features included via composer.

We need this in.

It sounds like what is left for this issue is to get it to pass the tests.

I started looking into making this. On the surface this seems to be the responsibility of Drupal/Core/Theme/ComponentPluginManager.php. That would be a place where we could later the schema validation logic of a Component definitition.

But the configuration shown above seems to be a solution that can be applied to each individual component schema definition. As in, it would be the responsibility of the developer to include the schema constraint per property.

Are you saying it's possible to modify the schema of a component, through the same config-based fix, that would impact the default definition of any property the component might have?

cosmicdreams → created an issue.

cosmicdreams → created an issue.

I don't think you did anything wrong. Much of what governs this system is automated. From what I can see you have been credited

Thank you, merged.

cosmicdreams → made their first commit to this issue’s fork.

Looks good.

cosmicdreams → made their first commit to this issue’s fork.

Thanks for your report. Reviewing your patch.

Thank you. Yes, this is resolved.

In rethinking this issue. I think we're due to a refactoring of the component css. I don't think we actually need to make the svgs a variable that the component can vary.

If these buttons were reused in some key way maybe, but right now they only have a single purpose. So it makes sense to only vary the bits that make sense.

As a bonus, by providing the svg definition via a full SVG tag, we can vary the fill / background color via css. That's not something we can do with a background-image url.

Thank you @avpaderno. We see that the rss stream is included in the list of RSS streams on the Planet: https://www.drupal.org/planet →

What we're trying to determine is whether or not our posts are being included in the stream and posted to the community. We've had two posts so far, we are struggling to prove that they are NOT included. We haven't seen them yet.

How would you recommend we debug this?

Ah, custom elements. If you're using custom elements, have you considered using Custom Events?

See: https://www.youtube.com/watch?v=wmGmKSLfVCY

This approach attempts to bubble up events from within a custom element, while also ensuring you have control over preventing events within the element from bubbling up.

@pdureau in your example above, what would the javascript look like. How would it use the "is" attribute?

cosmicdreams → created an issue.

Oh wait, I'm not actually seeing any change in your MR @mandclu

Looks good.

cosmicdreams → created an issue.

Yes, but I need to write a test for that.