🇺🇸United States @cosmicdreams

cosmicdreams → created an issue.

@laurii yea that's the ticket. And given that this appears to be working with XB, I bet you've got the live update of preview working.

This does beg the question about how Drupal core's preview functionality may change in a post-XB universe. Does it even make sense to attempt to provide this update capability to non-XB contexts?

Same Page Preview's use of NodePreviewController is merely to override the methods:

* view
* title

And we add a method:

* getPreviewUrl

But honestly we're not trying to do anything clever with it. We're just getting the output of the preview so we can shove it into an off-canvas dialog.

I'm hearing you say that you want to keep some kind of non XB preview functionality around, just something that ALSO works with workspaces. I'm all for that. I love workspaces already and thing XB's awesome. I'd like to help out in this space where I can.

There's just a lot going on that I'm not up to speed on. I don't know:

1. If Drupal's preview functionality can get any of that XB magic (I'd love to isolate the thing being built into it's own preview).
2. What the next steps are on any of this.

How can we continue this conversation?

cosmicdreams → created an issue.

Hey gang. Thanks for kicking off this conversation again.

XB's preview is very awesome. Laying out content from a composition of components is pretty awesome in practice too. I've been following along the best I can to try to answer to myself what further life Same Page Preview could have within a XB driven world.

At the heart of this discussion are the questions:

* How will users engage with content types in the future?
* Will they be in the practice of filling out fields on a traditional node edit page?
* Will there be any other structure that needs to be previewed that isn't directly connected to experience builder?

Keep in mind that all same_page_preview is doing is putting Drupal's existing preview functionality in a more prominent place on the page. So on a technical level, the maximum that I asking is, are we going to be removing NodePreviewController any time soon?

If you're going to remove existing ways of previewing content, then same_page_preview is dead. If not same_page_preview should be allowed to continue to exist if folks find it useful.

cosmicdreams → created an issue.

The issue here isn't actually the eca_ui module but rather that 📌 Convert from annotations to attributes Active broke compatibility with the annotations. I fixed the issue there, by using the backwards compatibility implementation outlined here: https://www.drupal.org/node/3395582 →

With that issue resolved the main issue I originally spoke about has been resolved. But a follow-up remained. So I'll repurpose this issue for it.

We need to convert the Annotation used in Drupal\eca_ui\Plugin\modeler_api_model_owner\Eca to use the new Attribute instead of the annotation. Really quick and easy fix.

That's great that folks are working on converting Annotations to Attributes in general.

I was specifically talking about the new plugin types that we are introducing in modeler_api. Without the backwards compatibility built into the Modeler and ModelOwner plugin managers, we will have the bugs I mentioned. I have quick fixes ready for:

• Drupal\eca_ui\Plugin\modeler_api_model_owner\Eca
• Drupal\bpmn_io\Plugin\modeler_api_modeler\BpmnIo

Both are the only ones (so far) to implement modeler_apis plugins. I'll go ahead and create issues and fixes for these and get this all wrapped up.

The issue I encountered in 🐛 Refactor breaks eca_ui Active was actually caused while working on this issue. It's obvious why now that I think about it a bit. I was able to create the Attributes, but need to use the "backwards compatibility" strategy outlined here: https://www.drupal.org/node/3395582 →

I'm going to create follow up issues for the ECA and BPMN.io modules to convert their plugins to use the Attribute syntax. I wonder if it would be helpful to keep the backwards compatibility implementation around until folks get used to writing Attributes instead of Annotations.

I also noticed that the way we are actually using the properties of the Annotation/Attribute is to put TranslateableMarkup in there (instead of just a string). Is it best to keep the property's data type to be a string instead of a TranslateableMarkup?

That's good to hear. Yea. checking if there's anything on my end that could be the issue.

Issue still occurs if you:

1. Start with a new Drupal 11-dev site
2. Enable eca
3. Enable eca_ui

Enabling eca_ui fails because it depends on a route that modeler_api creates. I'm even seeing the issue if I ensure that modeler_api is enabled first. I've cleared my cache a tone of times.

I think a different approach might be needed. Maybe if we use the same route_callback approach so we can programmatically set the route. We could check if the route already exists and if it doesn't, create a stub of the route. That way modeler_api can overwrite the route if eca_ui is installed first and eca_ui won't overwrite the route if modeler_api is installed first.

cosmicdreams → created an issue.

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

Yep, but later in the day after work things.

This initial effort needed a fix in order to properly use OO hooks. I needed to fix the autowiring manually.

cosmicdreams → changed the visibility of the branch 3517626--circular-reference to hidden.

I was able to determine that his bug actually belongs to the eca module. Specifically the eca_ui module.

A bit of issue queue sluething has uncovered that this is a recurring problem for some modules. The solution is to change the approach to lazy loading dependencies not through constructor injection but in getter injection. A practical example of this can be found in: https://www.drupal.org/project/filelog/issues/3416342 🐛 Circular reference detected for service Fixed

I was able to get the error to reoccur when manually enabling additional modules. This time I got a full call stack

The website encountered an unexpected error. Try again later.

Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException: Circular reference detected for service "plugin.manager.eca.action", path: "plugin.manager.eca.action -> eca.service.action". in Drupal\Component\DependencyInjection\Container->get() (line 147 of core/lib/Drupal/Component/DependencyInjection/Container.php).
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() (Line: 237)
Drupal\Component\DependencyInjection\Container->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 72)
Drupal\eca_ui\Plugin\modeler_api_model_owner\Eca::create() (Line: 21)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance() (Line: 85)
Drupal\Component\Plugin\PluginManagerBase->createInstance() (Line: 30)
modeler_api_entity_type_build() (Line: 118)
Drupal\Core\Entity\EntityTypeManager->Drupal\Core\Entity\{closure}() (Line: 315)
Drupal\Core\Extension\ModuleHandler->invokeAllWith() (Line: 117)
Drupal\Core\Entity\EntityTypeManager->findDefinitions() (Line: 213)
Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() (Line: 25)
Drupal\Core\Plugin\DefaultPluginManager->getDefinition() (Line: 132)
Drupal\Core\Entity\EntityTypeManager->getDefinition() (Line: 100)
Drupal\eca\PluginManager\Action->setCacheBackend() (Line: 38)
Drupal\Core\Action\ActionManager->__construct() (Line: 259)
Drupal\Component\DependencyInjection\Container->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 430)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() (Line: 463)
Drupal\Component\DependencyInjection\Container->Drupal\Component\DependencyInjection\{closure}() (Line: 55)
Drupal\Core\Plugin\CachedDiscoveryClearer->clearCachedDefinitions() (Line: 353)
Drupal\Core\Extension\ModuleInstaller->doInstall() (Line: 229)
Drupal\Core\Extension\ModuleInstaller->install() (Line: 83)
Drupal\Core\ProxyClass\Extension\ModuleInstaller->install() (Line: 175)
Drupal\system\Form\ModulesListConfirmForm->submitForm()
call_user_func_array() (Line: 105)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 43)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 589)
Drupal\Core\Form\FormBuilder->processForm() (Line: 321)
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: 600)
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: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 53)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 715)
Drupal\Core\DrupalKernel->handle() (Line: 19)

cosmicdreams → created an issue.

cosmicdreams → created an issue.

cosmicdreams → created an issue.

cosmicdreams → created an issue.

jurgenhaas → credited cosmicdreams → .

Yea, again, why not. Who knows how the integrations will evolve. But the idea of loading context will likely always be needed

cosmicdreams → created an issue.

cosmicdreams → created an issue.

Great work Benji

Additional thoughts:

* Talked with Jurgen this morning and discovered that there may be a strong need to move the existing BPMNModeler bits that are in the eca module into the BMPN.io module.
* So we can see what the moduler_api needs to know in order for that to work.

benjifisher → credited cosmicdreams → .

Revise the schema used in the full example.  It previously referred to Drupal 10.3, but for the future's sake, shouldn't refer to any specific version.

Weird I don't appear to have the ability to comment on the diff.

Are you adding in your own BPMN.io library? I wonder if we'll conflict with ECA if we do. I believe the BPMN bits of ECA is in it's own module. maybe we can depend on it without depending on all of ECA.

Worth a consideration?

cosmicdreams → created an issue.

I did this test:

1. Create the simplest content type. A content type with a title and body field
2. Create content with this CT
3. Export the content using the command line.
4. Import the content using the command line.

That succeeded. So even in my case I can prove that the system works (if given enough resources)

It is notable that the yaml file this export produced was about 63MB in size. (Uncompressed)

When I Previously ran into trouble, the content I was exporting was 173 MB in size.

After talking on slack with a few people, I've come to understand that this size is excessive. I would challenge you to test the size of your exports when working with content that has reference fields. I suspect that the export not only includes the content that was referenced (fully) but also the content that the reference references.

That would explain why the size of the export balloons.

OK, the next thing I tried was:

1. Create a "Simple" content type as simple as I can make it. I created a content type with just a body field.
2. Create content using this simple content type.
3. Export that using the drush content:export --entities=
4. Import content using drush content:import scs-export/

That succeeded but also included the error:

Drupal\search_api\SearchApiException while trying to index items on Acquia Search Solr Index: Could not index items on index 'Acquia Search Solr Index' because pending server tasks could not be executed. in Drupal\search_api\Entity\Server->indexItems() (line 363 of /var/www/html/docroot/modules/contrib/search_api/src/Entity/Server.php). 

Now, I have no evidence that my previous attempts were successful. I don't think it succeeded, didn't report its success, because of a search indexing error that occurred at the end.

But the fact that import can succeed if the complexity of the import is small enough points to a resource allocation issue. Do we know roughly how much resources one would need to import the giant files that export process can produce?

cosmicdreams → created an issue.

Weber is with 1 b

volkswagenchick → credited cosmicdreams → .

volkswagenchick → credited cosmicdreams → .

mherchel → credited cosmicdreams → .

cosmicdreams → created an issue.

This is a limiting factor for migrating to D11. Please prioritize.

Looks good to me as well.

mradcliffe → credited cosmicdreams → .

mradcliffe → credited cosmicdreams → .

cool. That's on deck for today.

Should this issue also be concerned with the MenuLinkContent entity. In general, do we introduce harm to the platform by declaring support for workspace within the Entity definition vs having the system determine an entity's support for workspaces through it's current logic?

I'll be able to test this patch tonight.

Update here, I'm finding the that clearing of the plugin cache is not a permanent solution. The issue recurs when you make another edit.

I'm starting to thing that the proper path to a solution here is to extend the menu_link_content entity to explicity declare that it has workspace support instead of indirectly compute it's workspace support as a result of the revision support that it has.

adding a line to the entity metadata makes this clear:

handlers = {
 *     "storage" = "\Drupal\menu_link_content\MenuLinkContentStorage",
 *     "storage_schema" = "Drupal\menu_link_content\MenuLinkContentStorageSchema",
 *     "access" = "Drupal\menu_link_content\MenuLinkContentAccessControlHandler",
 *     "form" = {
 *       "default" = "Drupal\menu_link_content\Form\MenuLinkContentForm",
 *       "delete" = "Drupal\menu_link_content\Form\MenuLinkContentDeleteForm"
 *     },
 *     "list_builder" = "Drupal\menu_link_content\MenuLinkListBuilder",
 *     "workspace" = "Drupal\workspaces\Entity\Handler\DefaultWorkspaceHandler"
 *   },

cosmicdreams → created an issue.

Progress?

Would be great to have a Drupal 11 version that composer can install.

teknorah → credited cosmicdreams → .

Is this still an issue since 8.x-1.30?

@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.