🇺🇸United States @segovia94

Thanks for the patch!

We are using the https://www.drupal.org/project/layout_builder_iframe_modal → module and are having failures for the same reason. The patch adding the dependency on the toolbar library doesn't help though because the the toolbar itself is not loaded within the iframe. So there will be errors that the toolbar library throws like Uncaught TypeError: document.querySelector('#toolbar-administration') is null.

I would recommend making the toolbar optional rather than a hard dependency. Currently, any site not using the toolbar will get errors.

You need to use '#type' => 'select'. Your code is set to '#type' => 'textfield'.

I would recommend moving the responsive css away from the previous "padding" hack to the widely supported aspect-ratio property. I'm happy to update the code to use it unless there is some legacy reason not to. The previous padding hack can create problems due to its use of absolute positioning.

There are examples within this module that work if you enable the development mode in config.
https://git.drupalcode.org/project/pdb_vue/-/tree/8.x-1.x/components

@nidhi27 I though the merge request would give you credit. Then I tried adding you to a commit message. I'm trying now through the checkbox below with a saved comment. Hopefully this applies the credit to you.

On second thought, changing the library names could break any components that have added those libraries as a dependency somewhere. Since core introduced this bug and has already created a fix for the next release I think we should leave this alone.

If someone needs a fix immediately, they should use the core patch here: 🐛 Improve "The libraries to include are encoded incorrectly" check and message Active

Open to other suggestions.

segovia94 → created an issue.

@nidhi27 thanks!

This may not be such a great idea after all. I may have been overthinking things originally. Having a UI to hide stuff from another UI seems unnecessary. I'm going to put this issue on hold for now.

You can do it via the settings,php file:

$settings['vite'] = [
  'overrides' => [
    // Per module/theme overrides.
    'my_base_theme_name' => [
      'useDevServer' => FALSE,
    ]
  ],
];

segovia94 → created an issue.

segovia94 → created an issue.

segovia94 → created an issue.

Those are demo blocks that will only work when the dev mode is enabled. https://www.drupal.org/docs/contributed-modules/decoupled-blocks-vuejs/g... →

moved the test to the correct file

Added the original test back in.

Since Drupal 9 is End of Life today, I am moving this issue to the contrib module and re-rolling the patch from #55.

segovia94 → created an issue.

It would be good to have the update checkbox behind a permission to prevent templates from being overridden by restricted users.

Moving to the new pdb_ng2 project.

Go ahead and merge this. I'll take care of docs in a new issue 📌 Update Docs to reflect the relocation of submodules Active all at once when all the submodules are gone.

segovia94 → created an issue.

Looks good.

I'll update the docs and readme to reflect this change.

Agreed. Because the ember submodule was no more than a stub, there is no need to create a separate project for the 2.x branch. It can be completely removed.

looks good

Clarify the base setting goes into the vite config file.

Changed the "components" directory to "vue_blocks" so it does not get confused with the Single Directory Component folder introduced in 10.1.

Config example updates.

Thanks for pointing this out. The values should now be escaped.

Removing the library dependency creates some breaks in other modules. I think the best thing would be to fix the ng2 module to ensure it has a correctly named library.

Duplicate of 📌 Automated Drupal 10 compatibility fixes Fixed . I went ahead and added you a commit credit on that issue.

segovia94 → created an issue.

Looks like this was from a change back in 9.1 https://www.drupal.org/node/3154407 → .

https://www.youtube.com/watch?v=pLcM3mpZSV0 is an interesting video of Laravel's new Nova admin interface. It uses Vue.js components that are controlled via PHP. This is a great approach because it allows the developers to continue using their existing PHP knowledge.

@lauriii thanks for the transparency on what the core team was evaluating when making their decision. It's much appreciated. One thing I will point out on the commit graph for maintainership, in an AMA with the Vue core team https://hashnode.com/ama/with-vuejs-team-cj7itlrki03ae62wuv2r2005s they mention that they are:

using the 'Squash and Merge' feature on GitHub when merging PRs, so the commit count isn't very representative of the community contributions.

As for the backward comparability break, it was pretty painless and nothing like the Angular transition. A recent article https://codeburst.io/an-overview-of-vue-js-and-the-future-of-the-framewo... addresses the future with version 3.

The main idea of ​​the Core team is simply to refine the API and internal code, as happened from v1 to v2

For those new to Vue and wondering how to define markup, here is a good breakdown of the different ways that templates can be defined. https://vuejsdevelopers.com/2017/03/24/vue-js-component-templates/

Although not my first choice in a normal project, Inline Templates (#4 in the article) might be the best bet for trying to make vue play nice with Drupal. This way the markup can go inside a normal Twig template. Wrapping Vue markup in twig's Verbatim Tag makes sure that twig doesn't try to parse Vue code.

{% verbatim %}
  <my-checkbox inline-template>
    <div class="checkbox-wrapper" @click="check">
      <div :class="{ checkbox: true, checked: checked }"></div>
      <div class="title"></div>
    </div>
  </my-checkbox>
{% endverbatim %}

By having it in normal twig files it allows themes to override or extend the twig file. This is really important in the long run to make sure that theme's have the ability to change markup as needed.