Velo Button Class

Ask the community
, ,
1

I need to add a class to a button but not through the $w().class function because I need that button to render with that class that I added. This is in connection with a 3rd party plugin that requires the button to have that specific class upon render of the page.

I am new, I saw that there’s an example to add class name to buttons before where there was an option beside property and events, but now that’s the there.

I did this, $w(“#recordbtn”).customClassList.add(“zstw_open”); but it doesn’t work. The SDK was already register in Add Element > Embedded Code > Custom Code > All Pages

Here’s what I am trying to do. (I don’t want to add Iframe via Embedded HTML, it looks ugly)

2

Hi, @LemKhn !!

Isn’t the menu for adding custom CSS classes still in the same place? :slightly_smiling_face:

3

Not there anymore. I saw in some documentation that it should be beside the Property and Events.

4

Hi, @LemKhn !!

Could it be that you’re confusing the regular Wix Editor with the Wix Studio Editor? :upside_down_face: As far as I know, the ability to add custom CSS classes is currently only available in the Wix Studio Editor. So, if you’re using the regular Wix Editor, that option may not exist. :slightly_smiling_face:

Also, in the Wix Studio Editor, custom CSS classes are meant to be written in a file called global.css.

/* in global.css */
.zstw_open {
    /* some custom css */
}

If you define your CSS there, then it’s possible to change the class using the kind of code you wrote. :innocent:

$w(“#recordbtn”).customClassList.add(“zstw_open”);
5

Thank you for the feedback. I am not adding a CSS Class but rather a 3rd Party required class which needs to be added together before the element is rendered.

Simply add the classname zstw_open to one or multiple elements you want to use as a launcher

Src: Web SDK | Birdie

6

I see. I often end up giving the same answer to this type of question, but I believe creating your own button using a custom element would solve the issue. Custom elements integrate more deeply with Wix sites, so if implemented well, they won’t look as visually awkward as iframes often do. Also, since custom elements can reference the content of your custom code, the specific class from the Birdie plugin you added (like zstw_open) should likely be accessible and work as expected. :innocent:

I haven’t tested it myself, but based on the code in the link above, you might want to try something like this as a very simple example, just to get an idea of how it works.

class CustomBirdieButton extends HTMLElement {
  connectedCallback() {
    this.innerHTML = `<button class="zstw_open">I'm customBirdieButton</button>`;
  }
}
customElements.define("birdie-button", CustomBirdieButton);

This is just a first-step idea.

7

Thank you for this.

Works perfectly in Preview mode. But after Publish, the button acted as if it’s a form submit button. It did not called the button’s function I declared for it inside the Custom Element.

Can you tell me what’s wrong?

8

Ok…I’m glad to hear that it’s working in preview mode for now. :slightly_smiling_face: It seems like we’re on the same page about what you’re trying to achieve, which is a good start. However, it’s still difficult to determine why it’s not behaving the same way on the live site. That said, if it works in preview mode, there’s usually a way to make it work on the live site too, so I think it’s worth experimenting a bit.

First, check the console on the live site to see if there are any errors being thrown.

Also, if I remember correctly, custom elements are rendered inside an iframe in preview mode. That could explain the difference in behavior between the preview and the live site. It might also be a matter of load timing.

So first, I’d like to confirm something: you mentioned embedding the plugin code inside your custom code—was it added in the head section? If not, please try moving it there.

Also, although it may not help, I’d suggest wrapping the code inside your connectedCallback function with a setTimeout and delaying it by about 10 seconds. It might seem pointless, but in cases like this, introducing a delay can sometimes reveal useful clues. If it does work with the delay, it’s likely a timing issue. :innocent:

Finally, if the plugin code includes the async attribute, you might want to try modifying that as well to see if it affects the behavior. :thinking:

If none of these suggestions work, I’m sorry in advance. :melting_face: