If a logged-in visitor to your Site has submitted a WebApp Item, they can now edit it too.
Most WebApps, including those created by the Admin and those created by visitors who are not logged in will not store the ID of a creator.
However, any WebApps created Front-End by a logged in User will store their creator's ID in the creator field.
In this example we create a variable by hard-coding a specific User ID.
You can now access the following fields inside a WebApp Layout:
{{this.creator.id}}
{{this.creator.name}}
{{this.creator.first_name}}
{{this.creator.last_name}}
{{this.creator.created_at}}
Under default settings, only a WebApp owner can see and also submit the edit form. A WebApp gets an owner when a user is logged in and submits the original WebApp create form. Their User ID is stored in the user_id field against the webapp.
It is possible to modify the owner of a WebApp in the Siteglide Admin.
It is also possible to set the "Anyone can edit" setting to true in the Siteglide admin in the "View Table" area for that WebApp.
Setting this to true means that default edit protections are removed for that WebApp on the front-end. You will then be responsible for writing your own Liquid code to wrap around the form if you wish to set custom Secure Zone permissions.
You could of course combine both of these features- creating a link to the same page including the creator_id as a query parameter and then filtering by that ID using context.params to fetch the ID from the URL.
Unlike the "Add" Form, the Front End WebApp Edit Form must be linked to the specific WebApp Item it will Edit. This means you can only output the Form inside a WebApp Detail or List Layout file.
To include the Edit Form inside a WebApp Layout, add the Liquid tag:
Parameters:
layout - Optional - Choose the name of your Layout file
The Edit Form will work if you use the same Layout as you used for your add Form.
However, you may wish to use an alternative Layout so you can add some additional features.
As you're including the Edit Form inside a WebApp Item, you have access to the WebApp fields that are inherited from the WebApp Layout.
One example might be adding a Title to the Form which dynamically references the WebApp Item: <h3>Edit {{this.name}}</h3>
Another example might be displaying the creator's name: <h4>By {[this.creator.name}}</h4>
In a Form Layout, we use the form_builder variable to dynamically add the correct name Attribute to inputs. You can use this to output the pre-filled value; instead of the name property, output the value property.
For this example WebApp field:
...you can use the name field and replace .name with .value to add a value attribute:
When you make a new WebApp, a front-end form file is automatically generated within your WebApp, in a folder called form. It automatically contains all fields from your WebApp. You can view this folder using Code Editor, it is next to the detail and list folders for your WebApp.
Output your WebApp form on a page:
Toolbox has support for WebApp input forms, and the following options will be given in the modal, or you can set them yourself:
enabled - default is false - Boolean - Determines if items are auto-enabled or not
expiry_date - default is never expires - Timestamp - When the new item will expire
release_date - default is as soon as the form is submitted - Timestamp - When the new item will be released
upload_dir - String - default is documents/form_uploads/webapp_1/ Where uploaded files will be stored. Must follow this format - 'folder/optional_folder/'
Some fields are required for the form to be able to set up the WebApp items correctly. These fields are for 'enabled', 'expiry_date', 'release_date', 'upload_dir', and 'slug'. They stay the same each form, and don't have a WebApp specific ID attached to them.
All forms should be wrapped in a Liquid form tag: `
` All forms need a submission button:`Submit`
This example can be used for a WebApp Submit form that is displayed within a the layout of another WebApp or Module.
this.category_array[0] - finds the first category the current item is categorised to and can be changed to be a full array, or specific category ID.
This example can be used on pages other than WebApp and Module layouts.
123456 - replace with the ID of a category of your choice.
Location Field (optional)
You can submit a Location value for a WebApp item as shown in the following example:
The value should be a stringified JSON object.
When your Users have created WebApp items front-end, you can now give them the option to delete the items they no longer need.
A User will only be able to delete a WebApp item they own. Generally a User will own a WebApp item they've already created, but it's now possible to change WebApp ownership in Admin. You can use Liquid to further control when the button is presented to Users.
This changes if you turn on "anyone can edit" for the WebApp in the Siteglide Admin. Then, you are responsible for adding your own custom Liquid logic to control access to the button.
You can use optionally use JavaScript to change the behaviour when the button is successful, or when it errors.
To include the delete button, add the following syntax inside a WebApp Layout of your choice
Nesting this inside a WebApp Layout allows it to easily pick up the ID of the current WebApp item.
We recommend wrapping the Layout in the following Liquid to make sure the button is only visible to those Users who have the minimum permission needed to successfully delete the current item:
Note that on the backend we will be running an additional check that the WebApp ID passed through is owned by the currently logged in User- so it won't be possible for malicious Users to delete items they don't own by passing through different IDs.
Including the button in Liquid as above will require a small Layout- which allows you to customise the way the button looks and functions.
Layouts for this button are stored at the following path: layouts/webapp_components/webapp_delete/my_layout.liquid
To make the delete button functional, you need to run the s_owned_webapp_delete() function on an event (usually a click event).
You should pass the following arguments:
You can add custom JavaScript functions to customise the way the button behaves on success and failure. Examples are included on the default layout.
If you don't provide custom functions, the default behaviour will be to:
On success, show a success message alert and reload the Page.
On failure, show an error message alert.
Here's an example of custom functions defined and then passed into the 3rd and 4th arguments in the function:
Note that the Siteglide Footer Scripts feature is a helpful tool to make sure your function definitions are only included in the Page once, avoiding duplicates as multiple iterations of the WebApp Layout are included on the Page. Just be aware that inline comments are not supported by this feature!
Additionally, you could add in custom behaviour before the main delete function runs, for example to provide a confirmation message to Users to check they really want to delete the WebApp item:
| Argument number | What is it? | Example |
|---|---|---|
1
This WebApp ID
{{this.id}}
2
Token
{{token}}
3
Optional custom success callback function name
webapp_delete_success
4
Optional custom error callback function name
webapp_delete_fail