Yes that is another way to do that. I tried to give you an explanation on how to do that without adding any other variable :)

I think the issue is that wire:loading.class.remove is doing the opposite of what you want here.

This:

wire:loading.class.remove="btn btn-disabled"

removes those classes only while Livewire is loading, then adds them back once the request is finished. So your button ends up disabled again after the upload completes.

Instead, start with the button enabled and only disable it while the upload is in progress:

<input type="file" wire:model="file">

<button type="submit" class="btn btn-sm btn-success">
    Upload file
</button>

<button
    type="button"
    wire:click="saveMetadata"
    class="btn btn-sm btn-primary"
    wire:loading.attr="disabled"
    wire:loading.class="btn-disabled"
    wire:target="file"
>
    Save Metadata
</button>

The important parts are:

wire:loading.attr="disabled"
wire:target="file"

wire:loading.attr="disabled" actually disables the button during loading, while wire:target="file" makes sure the loading state is tied specifically to the file upload property.

Also, if this button is inside a form, I’d explicitly set type="button" on the metadata button so it doesn’t accidentally submit the form.

One more note: if your upload button calls a Livewire method instead of relying directly on wire:model, you can target that method instead:

<button
    type="button"
    wire:click="saveMetadata"
    class="btn btn-sm btn-primary"
    wire:loading.attr="disabled"
    wire:loading.class="btn-disabled"
    wire:target="uploadFile"
>
    Save Metadata
</button>

So the general idea is: use wire:loading.attr="disabled" to disable the button during the upload, and use wire:target to make sure the loading state is only tied to the upload, not to every Livewire request.

Thanks for trying the demo, I really appreciate it.

Can I ask what specifically felt not intuitive to you?

Was it hard to understand what Tagixo is supposed to do, or was the problem more related to the actual UI of the builder, like adding elements, editing content, navigating between pages/forms, or understanding the workflow?

I’m asking because I’ve been working on it for a long time, so some things may feel obvious to me but not to someone opening the demo for the first time. Specific feedback here would be extremely useful.

Thanks a lot for the honest feedback. I really appreciate this kind of answer because it helps me understand what is not clear from the outside.

The original problem behind Tagixo comes from my own client work.

Many times I found myself building both a website and a custom management system for the same client. For speed, I often used WordPress with Divi for the website, while the actual business logic, workflows, data models, permissions and internal tools were built with Laravel.

The problem usually appeared when the website needed to display or interact with data from the Laravel backend. At that point, the frontend could no longer be managed visually and I had to build everything by hand. That is obviously fine in many cases, but it also meant duplicating effort and spending much more time on parts that, in my opinion, could have been managed in a more flexible way.

So the original idea behind Tagixo was not to replace Laravel, Filament, or custom development. It was to make a Laravel application capable of behaving more like a CMS when needed, with a visual builder integrated directly into the Laravel ecosystem.

The main audience is still developers. I am not trying to build a “no-code platform” where the developer disappears. My goal is to give Laravel developers a tool that can be used as a starting point, or as a flexible layer for the parts of an application that need to be editable, configurable, or reusable.

For example, Filament is great for building the admin panel and internal tools. Tagixo is more focused on the frontend side: pages, sections, content, forms, emails, PDFs and other parts that often need to be customized or maintained over time. There is also an official Filament plugin that makes Tagixo ready to use inside a Filament project. Forms can also be used inside Filament when a more dynamic form-building experience is needed.

So I see Tagixo less as “build your whole app visually” and more as “give your Laravel app a visual CMS-like layer where it makes sense”.

About trust, vendor lock-in and closed source: I completely understand the concern. As a developer, I would have the same doubts before adding a dependency like this to a real project.

The first thing I can say is that I am the first user of Tagixo. I built it because I needed it in my own work, and I intend to keep using it myself. If one day I were no longer able to maintain it, my intention would be to open-source it out of respect for the people who trusted the project.

Regarding breaking changes, I tried to design the system in a way that avoids real breaking changes as much as possible. Most classes are extendable, and many parts of the system are configurable. If a breaking change ever becomes necessary, I would provide a clear migration path and, where possible, migration scripts to help users move forward safely.

That said, I agree that I need to make this clearer in the documentation. Trust cannot be based only on what I say in a forum post. It needs to come from documentation, examples, stability, transparency, and real use cases.

About the server crash: you are right to point that out. It was bad timing and it was my fault. I was deploying some hotfixes for a mobile viewport issue on the website, and unfortunately some bugs only appeared in production. I had to restart the server while working on it.

That is not the kind of experience I want people to have when discovering the product, especially for a tool that should inspire confidence. I take that seriously.

Your point about Tagixo looking like a collection of features is probably the most important one for me. I think the product makes sense, but I clearly need to communicate the original problem better.

The problem is not “Laravel needs a visual builder for everything”.

The problem is that many Laravel applications eventually need editable pages, dynamic forms, reusable content, emails, PDFs, or client-managed frontend sections — and developers often have to rebuild those pieces from scratch every time.

That is the space where I am trying to position Tagixo.

Thanks again for the detailed feedback. It gives me a lot to improve, especially around positioning, documentation, trust, and explaining the actual use cases more clearly.

Hey everyone,

I’ve been working during the last year on a project called Tagixo, and I’d really appreciate some honest feedback from other Laravel developers.

The idea behind Tagixo is to bring a more visual editing experience to Laravel applications, without trying to move everything away from the Laravel ecosystem.

In short, it’s a visual builder that lets you create and manage things like pages, forms, sliders and reusable content blocks, while still keeping the developer in control of the application structure.

The reason I started building it is that I often felt there was a gap between two worlds.

On one side, Laravel gives us a very solid backend and developer experience.

On the other side, clients and non-technical users often expect a more visual way to edit content, similar to what they are used to in tools like WordPress page builders.

I wanted to explore whether something like that could exist in a Laravel-native way, without forcing developers to give up control or turn the application into a “black box”.

I’m mainly looking for feedback on a few things:

Does this kind of tool make sense in the Laravel ecosystem? Is the positioning clear enough? Would you consider using something like this in client projects or SaaS products? What would make you trust or not trust a visual builder inside a Laravel app? Are there any red flags from a developer experience point of view?

There is a live demo available, so it can be tested without installing anything locally.

Website: https://tagixo.com

To be clear, I know visual builders are not for every project, and I’m not trying to suggest that every Laravel app should be built this way. I’m mostly interested in understanding where the community sees value, where it sees risks, and what would be needed for this kind of tool to feel trustworthy.

Any honest feedback would be really appreciated.