It's not compatible with PHP ![]()
How about Basic?
![]()
As AI is not going anywhere employing skills would be a logical addition, we find this useful in many other IDE's:
- Install/import skills.md files
- Save/share/export skills.md files
![]()
Bump, as pinning seems to be broken?
Two more ideas:
- Directory level Security Restrict - API Directories containing multiple Actions can have Security Restrict applied so all contained Actions are secured by-proxy.
- NPM packages auto installed - I did it again yesterday adding an S3 Action and forgot to install the AWS SDK once again. This one is just lazy (I know we have the update packages), but a nice alert to update your packages would save me being an occasional idiot when I forget to do this (I say occasional, more frequent than occasional thoughI'll be honest..
).
This is already done automatically- each extension can specify its used modules and those are auto added to the package.json and installed.
Was that not the case with you and was it with a standard extension? They you should file a bug report.
If it was with some of your extensions, make sure you specified the used modules as per docs.
Was adding S3 step in a standard Server Connect Action. Probably just a Linux thing then George. I'll double check I didn't miss anything and if nothing happens I'll file the bug report.
Thanks for the advice!
![]()
Giving you more FREE time to sort out Wappler issues out then!! ![]()
![]()
Hahahaha..
Hello, if the topic concerns functionality, then let me add a couple of cents.
- A solution is needed for the visual development of any/flexible printed documents as a logical continuation of process modeling in SC/AC.
For example, take LiquidJS as a basis, as one of the most common template engines.
I haven't seen any ready-made visual template editors, there are attempts to make life easier for template developers, Wappler has all the elements to implement this.
Moreover, the visual development of LiquidJS templates and their logic based on real data can become a point of growth and attract customers for users of other systems.
- I do not know the number of users with a paid Wappler subscription, but there may already be an economic feasibility of implementing the professional version of AG Grid (or analogues, if any). For fast CRUD development with incredible speed of adding and managing data, tabular reports. Thanks to the community, we have the opportunity to integrate the AG Grid Community Edition, but the capabilities of the full version cover all possible needs of developers of tabular interfaces.
- The second point suggests the following idea, adding ready-made Kanban extensions, Gantt charts, and more.
That is, to make it so that using a Headless CMS (Directus, Strapi) as the backend of a project is more labor-intensive than quickly creating an administrative interface in wappler (I'm thinking from a beginner's perspective). - Editing and viewing JSON data in tabular format. It will allow using Wappler as a Flat-File CMS, expand the capabilities of the database manager to manage, for example, Graph databases and their data directly from the Wappler interface.
Iād like to add two items to the wishlist for Wappler 8āboth aimed at making databaseāheavy apps smoother to build and maintain:
- Database Views: Being able to define and manage SQL Views inside Wappler would simplify a lot of complex queries and help keep Server Connect actions cleaner.
- Data Table Seeds: A builtāin seeding mechanism for structured demo data would be incredibly helpful for migrations, testing, and spinning up new environments.
These would be fantastic qualityāofālife improvements for anyone building serious apps with Wappler.
Definitely yes on the Views! They are easy enough to create in NAvicat but would be great if it could be done in Wappler. Although that would probably mean using the database manager that I am not a fan of.
A basic queue functionality would be an incredible feature to have baked in. It is so useful in so many ways and would extend the Wappler toolkit immensely.
Reading through other suggestions the areas that stick out for me are:
- Tidying up connections/targets etc would be really useful, it works but it can get a bit confusing sometimes
- Git ignore to auto prevent certain files uploading to production would be great
- Personally I'm happy with bootstrap, but understand the desire for other css frameworks etc.
- Likewise server models, I use Node and am happy with it and hosting options available. I would support more choice, but would prioritise stability within what is already available.
- Custom snippets...would be a great timesaver, I often copy and paste form fields as the 'out of the box' blocks are often not quite what's reguired. The ability to define an html block and add anywhere would be so useful
- I do use AI sometimes and find it hit and miss, but improving (sometimes it creates havoc, but for page layouts, and troubleshooting it's a really useful tool). I haven't spent the time to explore proper wappler oriented prompting. I know development here is inevitable, but making manual, low code processing as simple as possible should be the priority with AI playing a supporting role imho.
- Extensions marketplace...if we want quality, supported extensions it's essential there's a simple way to make it at least mildly attractive for people to produce them, and sustain them.
Whilst I'm actually here much thanks to those who have provided some incredible tools and extensions recently. I read the post re. the forum recently and am guilty of not participating (partly as there is less participation so less need to post/feedback etc, partly using AI for troubleshooting etc):
@ben @Cheese @Hyperbytes and others I can't remember right now.
There a a huge number of extensions produced and supported by the amazing Wappler community. Why do you feel commercialising it would improve the situation?
It would only lead to pushing the extensions available now into a commercial platform.
There are some great extensions, and I genuinely value the community, and its support (in resolving issues, releasing extensions etc etc).
But for all the current, up to date extensions there are lots that are single issue fixes, not maintained, no longer compatible with current Wappler versions, relying on outdated dependencies etc.
As an example..this is seems likely to break a lot of extensions:
...maybe not instantly but as new hosting is set up for new projects on newer node versions, or existing hosting gets updated. Some extensions will be updated, some won't...how will we know which still work? Avoiding a 'hit and hope' position would surely benefit everyone... wappler, it's users and the people developing extensions.
I'd also suggest there are also a lot of extensions developed by people that they don't publish publicly as there's an immediate expectation of support, and no real way to compensate for this. The bigger the extension, the greater the risk.
My view is an extensions marketplace wouldn't need to detract from the communites input, and could work to better support it. But it could also open the door to some genuinely game changing features being available within wappler on a consistent and ongoing basis. With marketplace functionality like:
- Version control..direct visibility of compatible Wappler version/s (removing the fear of 'will this extension break if I update wappler', or vice versa)
- Free/Freemium options
- Support plans (or clarity around support expectations)
- Package pricing (all extensions from a dev for example)
- Better search/extension visibility...it's often hard to find extensions either via the forum or the installer
- Feedback/reviews alongside the actual extension at the time you are considering whether to install
Hey @sbecks,
Having created both a marketplace and Extensions I can say the marketplace idea is not the route to go. I made the mistake of trying to do this. I had some sales but the whole ethos was wrong (I shut it all down and simply offer my Extensions here now). Extensions should be free for all Users of Wappler and offered here on the Community (giving the User choice if they want to support the Developer with a 'coffee' for example). With regards to support and outdated Extensions that does need improving. Some Extensions are quite old and really need removing or at least marking as deprecated by the Developer themselves. Not all of those Developers are still active which is another issue. But then that goes for a lot of packages (NPM and Git offerings) so no different in that regard. There is always an idea of the Extensions 'condition' in the changelog (or date stamps for updates to repos etc). Outside of that it is difficult to ascertain, without installing the Extension, if it will indeed work or not.
For the most part feedback is very minimal yet it is incredibly valuable (thousands of downloads and only two or three pieces of feedback in my case). It gives those of us that create Extensions ideas and highlights issues we may need to pay attention to. I'm sure others here who have created Extensions can testify to that. It just doesn't exist though. Not even one percent give feedback from my experience. Back to the support side. Support is time consuming and we, for the most part, don't get paid for that, nor in many circumstances have the time, at the time, to offer guidance etc. This is why the readme is so important that it covers all the bases. Then there is the Community where any issues can be raised openly and supported accordingly when the Developer has time and is available.
So although the idea for a marketplace sounds like a logical approach the realities themselves are difficult to manage for those offering such a service. Then there are licensing issues on top. Not all Extensions are MIT. Mine are under my own license terms. Others may be under other license terms. So even still some Extensions would not be available on a marketplace. I'd not be willing to allow my own Extensions to be distributed in this manner. However I am happy to distribute them through the Wappler Extension Manager.
Just some insights as to the difficulties with the idea of a marketplace. Yes the idea is sound. The principle is good. The complexities and work to maintain it are something all together different. There are just so many factors to consider in making such an endeavor a success.
I agree 100% and feel an important question needs to be asked.
If there are so many broken extensions, why are users not reporting them. It is lazy to complain about issues then not bring them to the attention of developers.
Cheese makes a important point, i have around 30 published extensions, thousands of downloads but virtually no feedback on any of them.
Commercial or free, developers are dependent on feedback.
Do you think the Wappler team would find and fix all the Wappler bugs if nobody told them they were there?
And we wonder why the forum is quietā¦
Iām happy to be outvoted on the issue of paid extensions (though I, respectfully, disagree and feel itās a missed opportunity).
The main thrust of the suggestion (which was a small part of wider feedback, as requested in the thread) is to improve the way extensions are managedā¦.make feedback easy for users, link it to the dev, and directly to the extension so itās visible, allow devs to state if they have made something and put it up as a one off, or are supporting it, show which wappler versions extensions are compatible with etc etc. This is valid whether paid, or not. Some of this is appropriate to live in the forum, some of it really should be visible at the point of installing the extension. IMHO.
If extension users are having issues, and extension makers are having issues (lack of feedback etc) that suggests to me thereās an issue. Calling people (me?) lazy is not really a solution (even if it has some justification
)
I would also reiterate my genuine gratitude to all those that do create and provide extensions (supported and updated, or otherwise). This was never an attempt to get at anyone, just to provide constructive feedback and thoughts as asked.
Can help us out by telling us which Extensions you are having issues with?
All the Extensions are in the Extensions category right here. Feel free to provide details of any issues you encounter in the respective Extensions thread. Then we can take a look and see what we can do to resolve them.
For the most part Extensions are just JSON and a little JavaScript so compatibility is not so much a Wappler issue parse. However sometimes Extensions have dependencies. If those dependencies are not maintained by their respective Developer there is nothing any of us creating Extensions can do until we get feedback there is an issue (and try to resolve it either with an alternative or to deprecate the Extension all together). I for one don't have time to check every day on dependency issues. I'm happy to create Extensions and I try to keep any dependency to those that are maintained and updated. Outside of that we need Users to report issues.
Not so much outvoted as am sure there is some compromise along the lines... We just all have to work together to discover what that is. Discussions like this are valuable. Don't be dissuaded from raising these issues. As someone who creates Extensions I'm welcome to any feedback on the subject and appreciate it.
![]()