• I’m working on my header in the template parts. Everything works as intended until I try to add alpine.js inline to toggle my menu. For example if I were to add:

    <!-- wp:group {"className":"hdr__inner","layout":{"type":"default"}} -->
    <div class="wp-block-group hdr__inner" x-data="{ menuOpen: true }">
    
      <button @click="menuOpen = !menuOpen" >toggle</button>
    
      <!-- wp:group {"className":"hdr__nav-wrap","layout":{"type":"default"}} -->
      <div class="wp-block-group hdr__nav-wrap" x-show="menuOpen" :class="menuOpen ? 'hdr-open' : 'hdr-close';">
        Area to toggle
      </div>
      <!-- /wp:group -->
    
    </div>
    <!-- /wp:group -->

    Everything will work in the browser, I receive a “This block contains unexpected or invalid content.” in the editor.

    Is there a way around this that will allow me to add alpine or data attributes to my template parts?

    I also ran into the same issue when I was adding inline SVGs

Viewing 4 replies - 1 through 4 (of 4 total)
  • you would have to enqueue the scripts and add id and class in the editor.

    you can add classes and id in the advance section of the blocks.

    The blocks are javascript. The code you are displaying is from the editor. You will have to use the php enqueue scripts functions. You can create a plugin or do it in the functions.php file. You might find a block that will let you enqueue it from the editor. But, you can’t just add it to the document code.

    Thread Starter coachtest

    (@coachtest)

    Thanks for the reply. My javascript is already enqueued and is working in the browser it just breaks in the edit view.

    From what you are saying it sounds like a library like alpine.js [https://alpinejs.dev/] which is primarily relies on inlining into the html is not going to work in the editor view. Is there no way to encapsulate the x-data or any other code I would like the editor to ignore so it will show properly in both the front-end and edit view?

    • This reply was modified 2 years, 1 month ago by coachtest.
    • This reply was modified 2 years, 1 month ago by coachtest.
    Moderator bcworkz

    (@bcworkz)

    Using a custom HTML block for unusual HTML would be more forgiving than more specific blocks. It’s still not totally unrestricted. Even with the old classic editor we couldn’t enter any arbitrary HTML we wanted. In the classic editor, content was filtered through wp_kses_allowed_html(). I believe block content is still filtered through the same function, but I’ve not verified.

    It is possible to modify what HTML is allowed through the “wp_kses_allowed_html” filter. If using this filter doesn’t work for blocks, there could be a similar mechanism we could use. Specific block content tags are very restricted. You cannot really add anything that is not available through the usual UI. I believe this is the work of the block’s validation callback. The possibility of altering that is variable and may be non-existent in some cases.

    Thread Starter coachtest

    (@coachtest)

    Thanks for the reply. This is sort of what I figured would be the case. For now I’ll just avoid template parts and try and stick with patterns where there is a bit more wiggle room.

    I’ll also look into the filters you mentioned. Thanks again.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Adding Javascript to Template Parts’ is closed to new replies.