🇺🇸United States @cosmicdreams

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.

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