@lowdefy/docs-content 0.0.0-experimental-20260928120643 → 6.1.0

package/content/tutorial/tutorial-create-page.md

@@ -1,51 +1,5 @@
 # 2. Creating a page
 
-Let's create a page for a web form where users can log a new ticket.
-
-#### 2.1. Create `new-ticket.yaml`
-
-Create a new YAML file in the project directory (the same directory as the `lowdefy.yaml` file) called `new-ticket.yaml`, with the following content:
-
-```yaml
-id: new-ticket
-type: PageHeaderMenu
-properties:
-  title: New ticket # The title in the browser tab.
-layout:
-  justify: center # Center the contents of the page.
-blocks:
-  - id: content_card
-    type: Card
-    layout:
-      size: 800 # Set the size of the card so it does not fill the full screen.
-      gap: 16 # Make a 16px gap between all blocks in this card.
-    blocks:
-      - id: page_heading
-        type: Title
-        properties:
-          content: Log a ticket # Change the title on the page.
-          level: 3 # Make the title a little smaller (an html `<h3>`).
-```
-
-#### 2.2. Update `lowdefy.yaml`
-
-Change the `lowdefy.yaml` to look like this:
-
-```yaml
-name: lowdefy-project-template
-lowdefy: 6.0.0
-
-pages:
-################ -------- Copy from here -------- ################
-  - _ref: new-ticket.yaml
-################ -------- Copy to here ---------- ################
-  - id: welcome
-    type: PageHeaderMenu
-    properties:
-      title: Welcome
-    # ...
-```
-
 > Indentation is important
 
 #### 2.3. Navigate to the new page
@@ -79,13 +33,13 @@ menus:
       - id: new-ticket
         type: MenuLink
         properties:
-          icon: Siren
+          icon: AiOutlineAlert
           title: New ticket
         pageId: new-ticket
       - id: welcome
         type: MenuLink
         properties:
-          icon: home
+          icon: AiOutlineHome
           title: Home
         pageId: welcome
 ################ -------- Copy to here ---------- ################

package/content/tutorial/tutorial-display-data-page.md

@@ -140,20 +140,20 @@ menus:
       - id: welcome
         type: MenuLink
         properties:
-          icon: home
+          icon: AiOutlineHome
           title: Home
         pageId: welcome
       - id: new-ticket
         type: MenuLink
         properties:
-          icon: Siren
+          icon: AiOutlineAlert
           title: New ticket
         pageId: new-ticket
       ################ -------- Copy from here -------- ################
       - id: view-tickets
         type: MenuLink
         properties:
-          icon: Database
+          icon: AiOutlineDatabase
           title: View tickets
         pageId: view-tickets
       ############### -------- Copy to here ---------- ################

package/content/tutorial/tutorial-requests-sql.md

@@ -20,156 +20,3 @@ We will make use of an SQLite database with a table called `tickets`, that has t
 - created_date
 
 The database used in this tutorial can be downloaded <a href="/tutorial/tutorial_db.sqlite" download>here</a>.
-
-Alternatively, install [SQLite](https://www.sqlite.org/) on your computer and use the following to create the needed table:
-
-```
-CREATE TABLE tickets (
-  ticket_title varchar(100),
-  ticket_type varchar(50),
-  ticket_description varchar(200),
-  product varchar(100),
-  purchase_in_last_month real,
-  created_date real
-);
-```
-
-#### 6.2. Setting app environment variables
-
-Create a file called `.env` in your project directory with the following content:
-
-##### `.env`
-```
-LOWDEFY_SECRET_SQLITE_FILENAME= __ABSOLUTE_PATH_TO_SQLITE_DB_FILE__
-```
-
-#### 5.2.3. Setting the connection environment variable secrets
-
-In your `lowdefy.yaml` file, add the following:
-
-##### `lowdefy.yaml`
-
-```yaml
-name: lowdefy-project-template
-version: 6.0.0
-
-connections:
-  # ...
-################ -------- Copy from here -------- ################
-    - id: knex
-      type: Knex
-      properties:
-        client: sqlite
-        connection:
-          filename:
-            _secret: SQLITE_FILENAME
-################ ------- Copy to here ----------- ################
-
-menus:
-  # ...
-```
-
-#### 6.3. Creating a save data request
-
-In your `new-ticket.yaml` file, add the following request:
-
-##### `pages/new-ticket.yaml`
-
-```yaml
-id: new-ticket
-type: PageHeaderMenu
-requests:
-  # ...
-################ -------- Copy from here -------- ################
-  - id: save_new_ticket
-    type: KnexRaw
-    connectionId: knex
-    payload:
-      _state: true
-    properties:
-      query: |
-        INSERT INTO tickets (
-        ticket_title,
-        ticket_type,
-        ticket_description,
-        product,
-        purchase_in_last_month,
-        created_date)
-        VALUES(
-        :ticket_title,
-        :ticket_type,
-        :ticket_description,
-        :product,
-        :purchase_in_last_month,
-        :created_date)
-      parameters:
-        ticket_title:
-          _payload: ticket_title
-        ticket_type:
-          _payload: ticket_type
-        ticket_description:
-          _payload: ticket_description
-        product:
-          _payload: product
-        purchase_in_last_month:
-          _payload: purchase_in_last_month
-        created_date:
-          _date: now
-################ ------- Copy to here ----------- ################
-
-properties:
-  title: New ticket # The title in the browser tab.
-layout:
-  justify: center # Center the contents of the page
-blocks:
-  # ...
-```
-
-#### 6.4. Triggering the save data request
-
-In your `new-ticket.yaml` file, add the following action to the submit button:
-
-##### `pages/new-ticket.yaml`
-
-```yaml
-id: new-ticket
-# ...
-blocks:
-  - id: content_card
-    # ...
-    blocks:
-      - id: page_heading
-        # ...
-        # ...
-        # ...
-      - id: submit_button
-        type: Button
-        #...
-        events:
-          onClick:
-            - id: validate
-              type: Validate
-            ################ -------- Copy from here -------- ################
-            - id: save_new_ticket # Make a request to the SQLite database
-              type: Request
-              params: save_new_ticket
-            - id: reset # Reset the form once data has been submitted
-              type: Reset
-            ################ ------- Copy to here ----------- ################
-```
-
-If you click the submit button, your form data should be added into the tickets table.
-
-### What happened
-
-We set up the table and column names we will be using in our SQLite database. We need to do this to use the `SQLite` connection.
-
-We defined the `Knex` connection, with the SQLite client.
-
-We also defined a `KnexRaw` request, to save the data to our SQLite database, and called that request when clicking the submit button. This was done by making use of the `onCLick` event on the button to execute the [`Request`](/Request) action to make the API call.
-
-> You can find the final configuration files for this section [here](https://github.com/lowdefy/lowdefy-example-tutorial/tree/main/06-requests-sql).
-
-### Up next
-
-Next, we will add a new page to display all open tickets an a table.

package/content/tutorial/tutorial-start.md

@@ -4,7 +4,7 @@ In this tutorial, we will be creating a simple ticketing app that allows users t
 
 ### Requirements
 
-The Lowdefy CLI (Command Line Interface) is needed to run the development server. To run the Lowdefy CLI you need to install Node.js at version 24 or greater. If you don't have it installed, download Node.js from https://nodejs.org/en/download/, and follow the installation steps for your computer. All of the default settings given by the installer are fine for what we need. You will also need a text editor to modify the Lowdefy configuration files.
+The Lowdefy CLI (Command Line Interface) is needed to run the development server. To run the Lowdefy CLI you need to install Node.js at version 22 or greater. If you don't have it installed, download Node.js from https://nodejs.org/en/download/, and follow the installation steps for your computer. All of the default settings given by the installer are fine for what we need. You will also need a text editor to modify the Lowdefy configuration files.
 
 Lowdefy also requires [`pnpm`](https://pnpm.io/) to be installed. We recommend making activating [Corepack](https://nodejs.org/api/corepack.html), even though it is an experimental feature, as this is the simplest way to install `pnpm`. Alternative methods to install `pnpm` can also be found [here](https://pnpm.io/installation). To activate Corepack, run the following in your computer's command line interface (Windows CMD, Terminal on MacOS).
 
@@ -58,71 +58,6 @@ Made by a Lowdefy 🤖
 
 > __Error: Could not find "lowdefy.yaml"__: Make sure your current working directory contains the _lowdefy.yaml_ file. You can verify this by running the `dir` (Windows) or `ls` (MacOS) command.
 
-#### 1.5. Open the configuration file
-
-Open the `lowdefy.yaml` file using a text editor like [VS Code](https://code.visualstudio.com/download). The content of the file should look like this:
-
-```yaml
-lowdefy: 6.0.0
-name: Lowdefy starter
-
-pages:
-  - id: welcome
-    type: PageHeaderMenu
-    properties:
-      title: Welcome
-    slots:
-      content:
-        justify: center
-        blocks:
-          - id: content_card
-            type: Card
-            style:
-              maxWidth: 800
-            blocks:
-              - id: content
-                type: Result
-                properties:
-                  title: Welcome to your Lowdefy app
-                  subTitle: We are excited to see what you are going to build
-                  icon:
-                    name: heart
-                    color: '#f00'
-                slots:
-                  extra:
-                    blocks:
-                      - id: docs_button
-                        type: Button
-                        properties:
-                          size: large
-                          title: Let's build something
-                        events:
-                          onClick:
-                            - id: link_to_docs
-                              type: Link
-                              params:
-                                url: https://docs.lowdefy.com
-                                newWindow: true
-      footer:
-        blocks:
-          - id: footer
-            type: Paragraph
-            properties:
-              type: secondary
-              content: |
-                Made by a Lowdefy 🤖
-```
-
-This configuration completely describes the app you are running.
-
-#### 1.6. Make some changes
-
-Let's modify the button to link to the Lowdefy Discord community instead of to the Lowdefy docs.
-
-First, change `Let's build something` to `Join Lowdefy on Discord`, then save the file. Your page should automatically refresh and you should see the changed text of the button.
-
-Next, update the link url to the Lowdefy Discord link, replace `https://docs.lowdefy.com` with [`https://discord.gg/QQY9eJ7A2D`](https://discord.gg/QQY9eJ7A2D), then save the file. If you now click the button it should open a new window linking to the Lowdefy Discord Channel - Join our community to ask questions or learn more regarding Lowdefy ❤️
-
 ### What happened
 
 The Lowdefy CLI helps you develop a Lowdefy app.

package/content/user-authentication/login-and-logout.md

@@ -8,19 +8,15 @@ The `Login` action is used to start the user login flow. If only one OAuth provi
 
 The authorization url usually hosts a page where the user can input their credentials. After the user has logged in successfully, the user is redirected to the `/api/auth/callback/<provider_id>` route in the Lowdefy app, where the rest of the authorization code flow is completed. This URL usually needs to be configured in the identity provider's settings.
 
-The `callbackUrl` parameter of the Login action specifies where the user lands after login is complete. Three sources are consulted, in order: the `callbackUrl` param, then the `?callbackUrl=` query parameter Lowdefy sets when it redirects an unauthenticated user to the sign-in page, then the app's home page. If none resolves the action throws, rather than staying silently on the sign-in page.
-
-In a protected app a signed-out visitor is sent to the sign-in page for every URL, present or absent, so a `404` means you are signed in — see [Page and API existence](/auth-upgrade#page-and-api-existence-is-no-longer-observable-before-you-sign-in).
-
-To sign in without navigating at all - a login form in a modal, or an embedded panel - set `callbackUrl: false`. This is not valid for magic-link or social/OAuth sign-in, which redirect through a hop Lowdefy does not control.
+The `callbackUrl` parameters of the Login action specify where the user is redirected after login is complete. If `callbackUrl` parameters not set, the user will return to the page from which the action was called.
 
 The parameters are:
 - `authUrl: object`:
   - `urlQuery: object`: Query parameters to set for the authorization URL.
-- `callbackUrl: object | false`: Set to `false` to sign in without navigating. As an object:
+- `callbackUrl: object`:
   - `home: boolean`: Redirect to the home page after the login flow is complete.
   - `pageId: string`: The pageId of the page to redirect to after the login flow is complete.
-  - `url: string`: The URL to redirect to after the login flow is complete. An absolute URL is not `basePath`-prefixed, so it can be an external landing page.
+  - `url: string`: The URL to redirect to after the login flow is complete.
   - `urlQuery: object`: The urlQuery to set for the page the user is redirected to after login.
 - `providerId: string`: The ID of the provider that should be used for login. If not set and only one provider is configured the configured provider will be used. Else the user will be redirected to a sign in page where they can choose a provider.
 
@@ -95,164 +91,18 @@ events:
             screen_hint: signup
 ```
 
-## Magic link sign-in
-
-`Login` with `magicLink: true` emails the user a sign-in link. By default that link points straight at Better Auth's verify endpoint, which consumes the single-use token on the first `GET` of the URL.
-
-That is a problem in corporate inboxes. Mail security products — Microsoft Defender Safe Links, Proofpoint URL Defense, Mimecast — fetch every link in a message as it is delivered, so the scanner spends the token minutes before the person clicks, and the person lands on the error page with `INVALID_TOKEN`.
-
-Set [`auth.authPages.magicLink`](/auth-configuration#auth-pages) to a page in your app to close that gap. The email then links to your page, carrying the token and the callback destinations on its URL query, and a [`MagicLinkVerify`](/MagicLinkVerify) action on a **button click** walks to the verify endpoint. Fetching the landing page does nothing, so a scanner cannot consume the token.
-
-```yaml
-lowdefy: {{ version }}
-auth:
-  magicLink:
-    enabled: true
-  authPages:
-    magicLink: /magic-link
-```
-
-```yaml
-id: magic-link
-type: PageHeaderMenu
-blocks:
-  - id: content
-    type: Box
-    blocks:
-      - id: title
-        type: Title
-        properties:
-          content: Sign in
-          level: 3
-      - id: description
-        type: Paragraph
-        properties:
-          content: Click the button below to finish signing in.
-      - id: verify_button
-        type: Button
-        properties:
-          title: Sign in
-        events:
-          onClick:
-            - id: verify
-              type: MagicLinkVerify
-```
-
-The landing page must be reachable while signed out, so add it to `auth.pages.public`.
-
-Do **not** run `MagicLinkVerify` in the page's `onMount`, and do not auto-redirect to the verify endpoint. Some scanning sandboxes render the page and execute its JavaScript, so an automatic verify hands the token back to the scanner and you are no better off than linking at the endpoint directly. The whole protection is that a human has to click.
-
-The action needs no parameters: the token and the `callbackURL`, `newUserCallbackURL` and `errorCallbackURL` values are read from the landing page's own URL query, which the email put there. Pass parameters only to override them.
-
-## Email code sign-in
-
-With `auth.emailOTP` enabled the app can sign a person in with a code emailed to them. Unlike a magic link, the code is typed into the tab they started from — so it survives corporate mail security that pre-fetches links (and consumes the single-use link token), and it works when the email is read on another device.
-
-Two actions drive it:
-
-- [`EmailOtpSend`](/EmailOtpSend) sends the code to an email address.
-- [`EmailOtpVerify`](/EmailOtpVerify) signs the person in with the code they typed.
-
-`EmailOtpVerify` lands the user through the same three sources as `Login`: the `callbackUrl` param, then the `?callbackUrl=` query, then the app's home page. `callbackUrl: false` verifies without navigating — it is a plain JSON sign-in with no redirect hop, so staying put is valid here.
-
-### With magic link, one email carries both
-
-When `auth.magicLink` is enabled alongside `auth.emailOTP`, the magic-link email also carries the code, so one email serves both paths. Keep using `Login` with `magicLink: true` to send it — no change is needed — and offer `EmailOtpVerify` on the same page for people whose link does not work. `EmailOtpSend` is then only needed for a code-only page, where no link is offered at all.
-
-###### A sign-in page offering a code:
-```yaml
-id: email-code-login
-type: Box
-blocks:
-  - id: email
-    type: TextInput
-    required: true
-    properties:
-      title: Email
-  - id: send_code
-    type: Button
-    properties:
-      title: Send code
-    events:
-      onClick:
-        - id: validate
-          type: Validate
-          params:
-            regex: ^email$
-        - id: send
-          type: EmailOtpSend
-          params:
-            email:
-              _state: email
-        - id: sent
-          type: DisplayMessage
-          params:
-            content: Check your email for the sign-in code.
-  - id: otp
-    type: TextInput
-    properties:
-      title: Sign-in code
-  - id: sign_in
-    type: Button
-    properties:
-      title: Sign in
-    events:
-      onClick:
-        - id: verify
-          type: EmailOtpVerify
-          params:
-            email:
-              _state: email
-            otp:
-              _state: otp
-```
-
-An expired, mistyped or already-used code is the auth server rejecting the attempt, not an app fault: the action throws a `UserError`, so `onClick` `catch` actions run and the message displays, but nothing is reported to the server.
-
-## SMS sign-in
-
-`PhoneNumberVerify` completes a sign-in with an SMS code, and lands the user through the same three sources as `Login`: the `callbackUrl` param, then the `?callbackUrl=` query, then the app's home page. `callbackUrl: false` verifies without navigating.
-
-Two modes are exempt, because neither ends with the user arriving somewhere new:
-
-- `disableSession: true` creates no session to arrive with.
-- `updatePhoneNumber: true` is a signed-in user confirming a new number. They already had a session, and the confirmation usually runs in a modal a navigation would yank them out of.
-
-### Carrying the destination to a separate SMS form
-
-The `?callbackUrl=` query is read from the page the action runs on, and the unauthenticated bounce puts it on `authPages.signIn`. If your SMS form lives on its own page, the link that gets the user there has to carry the parameter, or the destination falls back to the home page:
-
-```yaml
-- id: to_phone_login
-  type: Link
-  params:
-    pageId: phone-login
-    urlQuery:
-      _if:
-        test:
-          _eq:
-            - _url_query: callbackUrl
-            - null
-        then: null
-        else:
-          callbackUrl:
-            _url_query: callbackUrl
-```
-
-The `_if` is what keeps a user who reached the sign-in page directly from being sent to `/phone-login?callbackUrl=null` — `urlQuery` serialises a null value rather than dropping the key.
-
 ## Logout
 
 When the `Logout` action is called, the user data and authorization cookies are cleared by the app.
 
-The `callbackUrl` parameter of the Logout action specifies where the user lands after logout is complete. Unlike the `Login` action it has no default and does not read the `?callbackUrl=` query: with no `callbackUrl` the page is reloaded and the server re-applies the page's auth rules, which sends a signed-out user off a protected page to the sign-in page.
+The `callbackUrl` parameters of the Logout action specify where the user is redirected after logout is complete. If `callbackUrl` parameters are not set, the user will return to the page from which the action was called.
 
 The parameters are:
 - `callbackUrl: object`:
-  - `home: boolean`: Redirect to the home page after the logout flow is complete.
-  - `pageId: string`: The pageId of the page to redirect to after the logout flow is complete.
-  - `url: string`: The URL to redirect to after the logout flow is complete. An absolute URL is not `basePath`-prefixed, so it can be an external logout landing page.
-  - `urlQuery: object`: The urlQuery to set for the page the user is redirected to after logout.
+  - `home: boolean`: Redirect to the home page after the login flow is complete.
+  - `pageId: string`: The pageId of the page to redirect to after the login flow is complete.
+  - `url: string`: The URL to redirect to after the login flow is complete.
+  - `urlQuery: object`: The urlQuery to set for the page the user is redirected to after login.
 - `redirect: boolean`: If set to `false` the user session will be cleared, but the page will not be reloaded.
 
 

package/content/user-authentication/users-introduction.md

@@ -29,11 +29,3 @@ The Login and Logout actions are used to start the login and logout processes.
 ## \_user operator
 
 The `_user` operator can be used to access data in the user object received from the identity provider. The OpenID Connect standard claims (fields like `name` or `email`) are mapped to the user object by default and addition fields can be configured using the `userFields` configuration option.
-
-### `two_factor_enrolled`
-
-`_user: two_factor_enrolled` is `true` when the caller holds a factor that satisfies [`auth.twoFactor.required`](/two-factor) — a TOTP enrolment **or** a registered passkey.
-
-It is a fact about the **user**, not the session: it does not assert that a factor was presented on this sign-in, only that the user has one on file. (The name is imperfect — a passkey is not literally a second factor. The field means precisely "holds a factor that satisfies `auth.twoFactor.required`", which a passkey does on its own.)
-
-It is present only on session-resolved callers. The API strategy and the injected callers used in dev and e2e carry no session and so do not carry this field.