Can you check in the network tab from devtools if all js files are downloaded successful and check the downloaded dmxAppConnect.js which version it is (you can view the response in when clicking on it within the network tab, check the header comment for the version number).
1 Like
From what I can tell all the js files are downloaded.
The dmxAppConnect.js version is
/*!
App Connect
Version: 2.0.0
(c) 2024 Wappler.io
@build 2024-04-16 12:46:52
*/
Not sure if this helps or not, but issues donāt seem to just be with rendering the bindings of data coming from the database. I just put my CMS in āMaintenance Modeā while using āStableā channel and it doesnāt redirect to the maintenance page as it should when user is not logged in. If I switch to App Connect 1 channel, the maintenance mode redirects properly.
I also viewed the count of js files that are downloaded in the console for each channel and they both download the same number of files. So I think all the same js files are loading.
So if I understand correctly you set html using the dmx-html attribute and that html contains App Connect components and expressions. The content inserted with the dmx-html attribute is not being parsed by App Connect, donāt think it was in App Connect 1 as well. Do you know the App Connect version from before the update?
I didnāt look before the updates, but when I switch to App Connect 1 channel this is the version as Iām sure you already know haha.
/*!
App Connect
Version: 1.14.12
(c) 2023 Wappler.io
@build 2023-03-14 12:22:18
*/
And this version seems to parse it fine. The only difference is the channel cause I donāt do anything different with the code on the page. Without it parsing I wouldnāt have even attempted to build a CMS cause I like being able to put the dmx bindings in the saved content.
Hereās the page with App Connect 1 and parsing fine.
Screen Recording 2024-04-18 at 12.00.14 PM
And here it is with Stable, look at the form and the copyright at the bottom. Also just noticed the menu is not showing properly on this version and that is not coming from the database, itās in a repeat in the header html.
Screen Recording 2024-04-18 at 12.04.14 PM
FYI 6.5.1 unfortunately didnāt fix any of the issues aboveā¦guess Iāll have to look deeper into my code and see if itās a similar thing that @mebeingken mentioned in another post:
Iāll add that the process of moving to AC2 has a way of exposing poor coding practices (at least it did for me!)
Mostly, it will highlight timing issues.
Here is a very simple example:
Previous code that worked under AC1 but (properly) failed under AC2
dmx-on:click="each_meal_type.remove($index);meal_type_ids_to_delete.addUniq(meal_type_id)"
As you can see it is 2 actions that are fired off together immediately since they are not in a flow. It removes an item from a form repeat, and also adds the id of the removed item to an array.
However with the improvements in AC2, things move much faster. In this case, the id needed from the form repeat item, is now gone (removed on the first action) by the time it attempts to add it to the array on the second action.
The solution here is to use a flow which will first add the item to the array, and then remove from the form repeat.
dmx-on:click="run([{run:{outputType:'text',action:`meal_type_ids_to_delete.addUniq(meal_type_id)`}},{run:{outputType:'text',action:`each_meal_type.remove($index)`}}])"
Given that my app is probably 5 years old now, I found several patterns I used like this that must now be cleaned up.
Iāll also add that I have AC2 in production for the last week, and I really appreciate the speed improvementsā¦they are noticeable if you have heavy client side processing.
Unfortunately your case is very different.
You are using the dmx-html attribute to inject a full blown html with components and such, which is not the best practice if this content is also generated by the user as it might present a security risk.
So a better way might be the use much more controlled layouts based and views and not just store and display any user generated layouts without sanitizing them.
This was also not supposed to work in AC1 but it seems like it was a bug that you have misused as a feature.
Yes thank you @George. I do plan on removing that feature of injecting full blown html from my app and just having the ability to show or not show the content sections per page. I wasnāt going to open that feature to users, just me for my convience of editing something via the app itself when I didnāt have Wappler with me for the very reason you stated, security risk. That said, my redirect checks for page access and maintenance mode etc arenāt working which may be an indication of poor coding on my part like ken mentioned in his app. Iāll probably strip the app down and rebuild bit by bit till I find the culprit or it gets rebuilt without the issue.
I think it would be very useful if at least simple strings, possibly including HTML (but not necessarily ā full blown htmlā), could be stored in a database and/or created dynamically in Server Connect and then parsed by App Connect. I asked about this 5 years ago, and there have several discussions about it since then - and at least 2 feature requests:
Allow parsing dynamic content retrieved from a server action before rendering it
Parse AC expressions stored in backend as strings
I didnāt realise it was ever possible with AC1, and I appreciate there are potential security risks. However, such a feature could be very useful in some situations (hence itās inclusion in most languages - and frameworks such Vue and React). Clearly, allowing anyone to enter whatever they like into a form where that text could then be executed is not a good idea. However, in a situation where such forms can only be accessed by users who manage the database, where the data entered is entered according to strict rules, and restricted and sanitised - there neednāt be a security risk.
1 Like
Iām still shocked that App Connect wasnāt supposed to be able to do it but somehow I got it to work haha. Still works in App Connect 1, but I am recoding that feature just in case this never comes to be in App Connect 2.
As for my access checks not working after the update, it appears to have been this issue that Ken reported.
In App Connect 1 it was actually a bug, it was a side effect that happens when the attribute inserted the html before the content was parsed. This only happens when data was already available or in repeaters where the content was parsed later.
1 Like
I liked that bugā¦haha
So the feature requests I mentioned will never be implemented in Wappler? I imagine as this is fundamental behaviour, it would be difficult to work round. (I can work round it using PHP, but I donāt know how feasible it would be with Node.)