Improved positioning at least via https://git.drupalcode.org/project/migrate_visualize/-/merge_requests/17
xurizaemon → created an issue.
The change record didn't clearly communicate the required fix here for me, and I overthought it.
Solution (I now believe!) is to add langcode: en
to the default configuration yaml files in the module's config/install
folder.
benjifisher → credited xurizaemon → .
xurizaemon → created an issue.
I haven't forgotten about this! I've been making some progress over on 📌 Connect pseudofield sources to use in pipeline Active which is adjacent.
I think if we pull the BPMN JS libraries in directly (as is done for Mermaid currently), we can then output the diagram in BPMN notation, and I don't expect that to take much refactor as we are adding a third output format (GraphViz, Mermaid, BPMN) to an implementation which currently delivers two.
I expect this would trigger renaming the `migrate_visualize/js` JS to `migrate_visualize/mermaid` and adding a similar JS to initialize BPMN.
That solves the "what might ECK / BPMN do" issue. If such an integration module for BPMN does appear, we can always switch to that later. For now, CDN inclusion is fine by me; this is a dev module.
Pseudofield edges are working now, but the chart isn't yet to my liking.
The following module-generated Mermaid works on mermaid.live, but doesn't in the module's render of the same output. I'm having trouble activating the Elk layout renderer.
--- # Generated with Migrate Visualize # https://drupal.org/project/migrate_visualize --- flowchart LR subgraph Source[fa:fa-cloud-download Source] source:meta:plugin["plugin: url"] source:field:id["id"] source:field:title["title"] source:field:link["link"] source:field:updated["updated"] source:field:data["data"] source:field:content["content"] source:field:constants_subtype["constants/subtype"] source:field:__path_parts_3["@_path_parts/3"] source:field:__path_parts_4["@_path_parts/4"] source:field:__term_names["@_term_names"] end subgraph Destination[fa:fa-cloud-upload Destination] destination:meta:plugin["plugin: entity:node"] destination:field:created["created"] destination:field:changed["changed"] destination:field:title["title"] destination:field:type["type"] destination:field:field_remote_id["field_remote_id"] destination:field:field_data["field_data"] destination:field:field_subtype["field_subtype"] destination:field:_path_parts["_path_parts"] destination:field:_term_names["_term_names"] destination:field:field_tags["field_tags"] destination:field:field_url["field_url"] end subgraph Process[fa:fa-cloud-upload Process] process:field:created["created"] process:field:created:1["format_date"] process:field:changed["changed"] process:field:changed:1["format_date"] process:field:title["title"] process:field:title:0["get"] process:field:type["type"] process:field:type:0["default_value"] process:field:field_remote_id["field_remote_id"] process:field:field_remote_id:0["get"] process:field:field_data["field_data"] process:field:field_data:1["callback: json_encode"] process:field:field_subtype["field_subtype"] process:field:field_subtype:1["entity_generate"] process:field:_path_parts["_path_parts"] process:field:_path_parts:1["skip_on_empty"] process:field:_path_parts:2["explode"] process:field:_term_names["_term_names"] process:field:_term_names:0["get"] process:field:_term_names:1["callback: array_filter"] process:field:_term_names:2["callback: array_unique"] process:field:field_tags["field_tags"] process:field:field_tags:1["entity_generate"] process:field:field_url["field_url"] process:field:field_url:0["get"] end source:field:updated --> process:field:created:1 process:field:created:1 --> process:field:created process:field:created --> destination:field:created source:field:updated --> process:field:changed:1 process:field:changed:1 --> process:field:changed process:field:changed --> destination:field:changed source:field:title --> process:field:title:0 process:field:title:0 --> process:field:title process:field:title --> destination:field:title process:field:type:0 --> process:field:type process:field:type --> destination:field:type source:field:id --> process:field:field_remote_id:0 process:field:field_remote_id:0 --> process:field:field_remote_id process:field:field_remote_id --> destination:field:field_remote_id source:field:data --> process:field:field_data:1 process:field:field_data:1 --> process:field:field_data process:field:field_data --> destination:field:field_data source:field:constants_subtype --> process:field:field_subtype:1 process:field:field_subtype:1 --> process:field:field_subtype process:field:field_subtype --> destination:field:field_subtype source:field:link --> process:field:_path_parts:1 process:field:_path_parts:1 --> process:field:_path_parts:2 process:field:_path_parts:2 --> process:field:_path_parts process:field:_path_parts --> destination:field:_path_parts source:field:__path_parts_3 --> process:field:_term_names:0 source:field:__path_parts_4 --> process:field:_term_names:0 process:field:_term_names:0 --> process:field:_term_names:1 process:field:_term_names:1 --> process:field:_term_names:2 process:field:_term_names:2 --> process:field:_term_names process:field:_term_names --> destination:field:_term_names source:field:__term_names --> process:field:field_tags:1 process:field:field_tags:1 --> process:field:field_tags process:field:field_tags --> destination:field:field_tags source:field:link --> process:field:field_url:0 process:field:field_url:0 --> process:field:field_url process:field:field_url --> destination:field:field_url destination:field:_term_names --> source:field:__term_names
Mermaid.live rendering with Elk:
Migrate Visualize rendering without Elk:
Looks like I've broken the "copy source" JS with WIP also.
I intended to create the issue relating to the organisation from the shared account which owns node 1802754, but I was not able to create the node as that user, nor add a comment as that user giving approval. (Shared accounts have limited access to the issue queue.)
You may check with that shared account's email to verify, before making the change, to confirm this is OK.
xurizaemon → created an issue.
xurizaemon → created an issue.
Thanks so much! Your persistent effort is much appreciated :)
fubarhouse → credited xurizaemon → .
xurizaemon → created an issue. See original summary → .
fubarhouse → credited xurizaemon → .
jct321 → credited xurizaemon → .
xurizaemon → created an issue.
Thanks heaps Khaled! Nice fix.
xurizaemon → made their first commit to this issue’s fork.
Merged, setting back to Active for future updates.
Another user has said in Slack today that "Google Search Console reports an indexing issue because it does not support nested sitemap indexes". I've directed them towards this issue. Perhaps Google has recently changed behaviour; hopefully someone with a GSC account and a site big enough to hit this is able to provide more detail.
Hi @cosmicdreams! Apologies for missing this issue posted here until you raised the topic in Slack the other day :)
BPMN does look cool, and I am interested to have an explore of making that work within this module. (I am happy to support progress on that within this module, and I am also happy for that progress to happen in some other module. If this is the right place for it, great!
There is another issue raised at ✨ [Spike] Change to BPMN.iO Active - eventually one will be closed duplicate, but no rush. For the most part this module has been unmaintained the last few years ... I had the opportunity of a sprint at DrupalSouth today, so I got things a bit tidied up, intending to support BPMN output as a third option.
I don't (yet) believe we need to replace GraphViz? I implemented both GraphViz and MermaidJS in round one of this module, and it should function OK without GraphViz, falling back to MermaidJS only if there's no server support. So I'm changing the title to "Add BPMN output format" because if we add BPMN we will have three options for display.
At this stage, I believe that missing GraphViz should be handled in the UI of this module. If you're aware of an issue that occurs when the server lacks GraphViz support, please open a specific bug report for that, and I'm happy to look into it. Please include steps to reproduce and observed behaviour when doing so. See Drupal\migrate_visualize\Form::buildForm() source for more.
So far I like the idea of providing for BPMN, and I am glad that the existing (1.x) version provides for multiple outputs.
Even if it doesn't conflict with BPMN, I don't think it's the role of this (developer-targeted) module to depend on ECA. Currently the BPMN.io module depends on ECA (which was odd to see, but it appears the BPMN.io module functionality adds BPMN to ECA). Noting also that there's BPMN.io and bpmn-js. My concern here is that if Migrate Visualize depends on ECA, adding Migrate Visualize as part of migration development and review can have architectural impacts on the site in question.
I see there is also an existing issue at ✨ Consider replacing GraphViz Active which proposed investigating BPMN. (I'll update the title of that issue so it mentions BPMN!)
I plan to take a look at whether we can introduce BPMN's JS in a similar manner to how we introduce MermaidJS. I'd use a CDN for this if possible. There's an assumption here that the use of BPMN is similar to MermaidJS and GraphViz, ie that we're visualizing the migration, rather than implementing a visual configuration editor (which would be outside the scope of this module).
xurizaemon → created an issue.
xurizaemon → made their first commit to this issue’s fork.
xurizaemon → changed the visibility of the branch 2.0.x to active.
xurizaemon → changed the visibility of the branch 2.0.x to hidden.
xurizaemon → created an issue.
Thanks @restoismile for input. It's clearer for other collaborators to use the existing merge request rather than add a patch which I then need to compare to the MR. Drupal's Gitlab process allows you to add your own changes, and you'll then receive credit more properly too.
- https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →
I believe the additional change you're proposing (restoring!) is in src/MenuBasedBreadcrumbBuilder.php
:
-+ $raw_parameters = (array) $route_match->getRawParameters(); ++ $raw_parameters = (array) $route_match->getRawParameters()->all();
I suspect the (array)
there is redundant and can be removed if we use ->all()
?
Would you please take another look and propose the change via the MR? That will help this issue to progress more easily.
If the issue already has a MR open, that should be preferred for collaboration.
hestenet → credited xurizaemon → .
lhridley → credited xurizaemon → .
@lhridley, fixes for cspell and eslint are in https://git.drupalcode.org/project/flysystem/-/merge_requests/84 now
Perfect, thanks! I will sort out cspell and linter job failures in this issue.
xurizaemon → created an issue.
Current status is that https://git.drupalcode.org/project/flysystem/-/pipelines/393131 is passing, but not green (fails on: cspell, eslint, phpstan).
I'm happy to progress that to green if you want @lhridley?
Does 🐛 Missing route cachability metadata. Active address this for you, or maybe provide a start point for how the behaviour you're observing can be addressed?
Tests pass, and the small change here looks good to me. Merged to 2.0.x.
Thanks @kbriand. Converted to MR so we get tests run - please use the merge request to progress work from here.
xurizaemon → made their first commit to this issue’s fork.
Rebased against 2.0.0 after recent updates ( 🐛 Drupal\menu_breadcrumb\Form\SettingsForm is incompatible with ConfigFormBase Active ).
Rebased against 2.0.x after release of 2.0.0.
I think this will have been fixed now?
-
🐛
Passing null to $typedConfigManager in ConfigFormBase::__construct() is deprecated
Active
-
🐛
Drupal\menu_breadcrumb\Form\SettingsForm is incompatible with ConfigFormBase
Active
Please re-open if there's more to do.
Well, let's release it then: https://www.drupal.org/project/menu_breadcrumb/releases/2.0.0 →
Huh, just noticed discussion in related issue, linking!
📌 Menu Breadcrumb - Update logo Fixed
Thanks Leslie!
Done, thanks!
OK, I think I will go with the classic MacOS looking logo, mostly for whimsical "let's pick one for now" reasons.
The first logo posted to this thread didn't really make sense to me - visually I get "breadcrumbs above the menu", which feels sort of backwards, but also "breadcrumb" for me is a computing term which is not communicated well by a picture of the item, especially in icon / vector style (is it gold? rocks? crumbs? etc).
Thanks for the contribution - appreciated, and crediting for the work.
Here's how those three logos look in the Project Browser. (mockup only)
LeslieG, still interested in your answer on the logo proposed.
Here's the one you proposed:
When I looked at this issue, I found a logo I'd made (Feb 11 2023?!), which I'd totally forgotten making, and had been waiting in a local git repo on my laptop! Attaching here. "It's OK" but not great.
But I didn't notice that until I'd made a second attempt at it, which is this one. This time I had in mind the Classic MacOS menu.
Decisions, decisions ...
I'll mark it fixed then, I _think_ already copied credit over to 🐛 Drupal\menu_breadcrumb\Form\SettingsForm is incompatible with ConfigFormBase Active . Thanks!
xurizaemon → created an issue.
Hi, want to rebase / re-test this now that 🐛 Missing route cachability metadata. Active has landed?
Thanks @dieter, added to issue description
Rebased, tidied and merged, thanks both!