# General SleekView is a WordPress plugin for building structured admin views on top of existing content and custom data sources. Instead of forcing you into a new content model, it lets you decide how data should be visualized, filtered, and worked with. ## Core Philosophy Your data should stay in the system that already owns it. SleekView adds view logic on top of post types, custom database tables, APIs, files, and presets so that you can manage workflows without rebuilding the underlying storage layer. ## Key Features - **Custom Views**: Render the same source as a table, kanban board, feedback list, or chart dashboard - **Modern Data Sources**: Connect post types, custom tables, HTTP CSV/JSON/JSONC, media files, WordPress-relative files, SQLite databases, custom REST URLs, and PHP presets - **Server-Side Querying**: Search, filter, sort, paginate, and export without loading entire datasets into the browser - **Data Independence**: Keep your existing WordPress and custom data structures intact - **Post Type Workflows**: Inline editing, drag and drop, submissions, upvotes, and other write actions stay available on post type views - **Frontend Integration**: Display views on public pages using shortcodes ## Use Cases SleekView adapts to a wide range of workflows and data setups. Common examples include: - Editorial calendars for content teams - Project management boards for custom post types - Internal dashboards backed by custom tables - Chart dashboards for reporting on status, type, revenue, inventory, or progress - Public roadmaps backed by external JSON or CSV data - Feedback boards connected to post types or read-only custom sources - Operational overviews for REST APIs and SQLite datasets - Document and inventory views built from imported files The plugin is designed so you can keep adding view layers as your data model expands, instead of replacing the systems you already depend on. --- # Activating `` SleekView can be activated on a site by navigating to the `SleekView` menu item in the WordPress admin dashboard. Alternatively, it is also possible to activate SleekView using PHP. This is done by adding the following code constant to your `functions.php` file: ```php const SLEEK_VIEW_LICENSE = "YOUR LICENSE KEY"; ``` --- # Settings - License The License section is where you activate your plugin by entering your license key. A valid license ensures you receive automatic updates and have access to all premium features. ## Adding Your License Key 1. Enter your license key in the provided field 1. Click the "Set Key" button to validate and activate your license Once activated, your license key will be securely stored and automatically validate your installation for updates. ## License Status After entering your key, the system will automatically verify its validity. --- # Views - General These global settings apply to all views and can be found in the configuration sidebar on the right when editing a view. ## General Settings ### Name The display name for this view. This name appears in the tab navigation when multiple views are configured for the same post type. ### Post Type Select which WordPress post type this view will manage (e.g., Posts, Pages, or any custom post type). This is used when the data source is set to Post Type. ### Data Source Choose where the view pulls its data from. The default is Post Type, but you can also connect custom tables, HTTP CSV/JSON/JSONC files, media library files, WordPress-relative files, SQLite databases, custom REST URLs, or registered PHP presets and integrations. See [Data Sources](https://fabrikat.local/sleek/view/documentation/views/data-sources) for detailed configuration options and feature differences. ### Disable view Toggle this option to temporarily disable the view from rendering in the admin. The view configuration is preserved, but it won't appear in the admin interface. ## Shortcode Each view has a unique shortcode that can be used to display the view on the frontend. This allows you to embed interactive views anywhere on your site: ```php [sleek-view-widget id="123"] ``` Copy this shortcode to embed the view anywhere on your site. The view will remain fully interactive on the frontend, allowing users to interact with content as configured in your view settings. ## Conditions See [Conditions](https://fabrikat.local/sleek/view/documentation/views/conditions) for detailed information on controlling view visibility based on user roles, environment, or other conditions. --- # Views - Data Filtering ## Data Filtering Located in the configuration sidebar on the right, the Data Filtering accordion contains powerful options for precisely controlling which content appears in your view. You can build complex queries using AND/OR conditions: ### Add multiple filter groups (connected with AND) - Within each group, add multiple conditions (connected with OR) - Filter by any post field, meta field, or taxonomy - Use various operators like equals, contains, greater than, etc. ### Examples - Show posts with status "published" AND category "news" - Show tasks with (priority "high" OR deadline "this week") AND assigned to "current user" The filtering system is dynamic - any changes you make are immediately reflected in the preview area, helping you fine-tune your view's content exactly how you want it. --- # Views - Conditions SleekView's powerful conditions system allows you to control when views, tabs, and individual switches should be active or visible. This is particularly useful when views are embedded on the frontend or when you need role-based access control. ## How Conditions Work Every view and most switches within view configurations support custom conditions. These conditions determine whether the feature should be active based on the current environment, user, or context. ### Setting Conditions When you see a "Set conditions" button next to a switch or in a view's settings, you can click it to open the conditions interface. This interface uses an AND/OR repeater system for building complex logic: - Multiple conditions within a group are connected with **AND** (all must be true) - Multiple groups are connected with **OR** (at least one group must be true) ## Available Parameters ### Environment #### Is Admin Determines whether the view is being displayed in the WordPress admin area or on the frontend. This is particularly useful for views that can be embedded via shortcode. - **is equal to true**: Show only in admin area - **is equal to false**: Show only on frontend (embedded views) ### User #### User Filter by specific user ID. Useful for creating personalized views for individual users. #### User Role Filter by WordPress user role (e.g., Administrator, Editor, Author). This allows you to show different features to different user groups. ## Examples ### Admin-Only Editing You might want to allow editing in the admin but disable it on the frontend: - **Parameter**: Is Admin - **Operator**: is equal to - **Value**: true This would make the "Show edit button" only appear when the view is displayed in the WordPress admin. ### Role-Based Features Show upvotes only to logged-in users with specific roles: - **Parameter**: User Role - **Operator**: is equal to - **Value**: subscriber ### Complex Conditions You can combine multiple conditions for more sophisticated logic. For example, to show a feature only to administrators in the admin area: **Group 1 (AND)** - **Parameter**: Is Admin - **Operator**: is equal to - **Value**: true **AND** - **Parameter**: User Role - **Operator**: is equal to - **Value**: administrator ## View-Level Conditions Every view has a Conditions section at the bottom of its configuration panel. These conditions control the entire view's visibility. If the conditions aren't met, the view tab won't appear at all. ## Switch-Level Conditions Individual switches within view configurations can also have conditions. For example: - **Show upvotes**: Set conditions to only show upvotes on the frontend - **Show edit button**: Set conditions to only show for administrators - **Show add button**: Set conditions to disable adding in embedded views - **Show comments**: Set conditions based on user roles ## Best Practices 1. **Frontend vs Admin**: Use "Is Admin" conditions to differentiate between admin and frontend behavior 2. **Progressive Enhancement**: Start with basic functionality for all users, then add conditions for advanced features 3. **Test Both Contexts**: When using "Is Admin" conditions, test both in the admin area and via shortcode embeds 4. **Role-Based Access**: Use User Role conditions to create different experiences for different user types Conditions provide incredible flexibility in how your views behave in different contexts, making SleekView adaptable to virtually any content management scenario. --- # Views - View Configuration Each view in SleekView can be fully customized through the configuration sidebar on the right. The available settings depend on the view type you've selected. ## Configuration Structure The configuration sidebar contains several sections: - **General**: Basic view settings like name and type - **Data Source**: Choose between Post Type, Custom Table, Custom REST URL, HTTP CSV/JSON/JSONC, Media CSV/JSON/JSONC, Path CSV/JSON/JSONC/SQLite, or a registered preset - **Data**: Filtering options to control which content appears - **View-Specific Settings**: Additional tabs that vary based on the view type - **Conditions**: Control when the view should be visible - **Shortcode**: Code to embed the view on the frontend ## View Types SleekView offers four different view types, each optimized for specific content management and reporting scenarios: ### Table View A powerful spreadsheet-like interface with advanced sorting, filtering, and data export capabilities. Perfect for managing structured data and large datasets. [Learn more about Table View →](https://fabrikat.local/sleek/view/documentation/views/table) ### Kanban View A visual, card-based interface for managing workflow-oriented content. Post type cards can be dragged between columns, while external sources render the same board structure without write actions. [Learn more about Kanban View →](https://fabrikat.local/sleek/view/documentation/views/kanban) ### Feedback View Designed for collecting and managing user feedback or feature requests. Post Type sources support interactive feedback workflows, while external sources can render the same structure in read-only mode. [Learn more about Feedback View →](https://fabrikat.local/sleek/view/documentation/views/feedback) ### Charts View A visual dashboard view for reporting on the current dataset. Charts can show number cards, area charts, bar charts, line charts, pie and donut charts, radar charts, and radial charts. [Learn more about Charts View →](https://fabrikat.local/sleek/view/documentation/views/charts) ## Understanding Conditions Many settings within views support custom conditions that control when they should be active. This is particularly powerful when views are embedded on the frontend or when you need role-based access control. [Learn more about Conditions →](https://fabrikat.local/sleek/view/documentation/views/conditions) ## Multiple Views You can create unlimited views for each post type. For example, you might have: - A Table view for data analysis - A Kanban view for workflow management - A Feedback view for user submissions - A Charts view for reporting and dashboards All for the same post type, each serving a different purpose. Users can switch between views using the tab navigation at the top of the screen. ## Default Tab By default, SleekView replaces the standard WordPress post table with your custom views. However, you can enable the "Default" tab in your view settings to provide access to the original WordPress table view alongside your custom views. --- # Views - Table The Table view provides a powerful, spreadsheet-like interface for managing your content. It offers advanced sorting, filtering, and data export capabilities along with inline editing support. All settings for the table view are configured through the sidebar on the right when editing a view. ## General Settings ### Name The display name for this view. This name appears in the tab navigation when multiple views are configured for the same post type. ### Type Select "Table" as the view type. This determines the available configuration options and how content is displayed. ### Disable view Toggle this option to temporarily disable the view from rendering in the admin. The view configuration is preserved, but it won't appear in the admin interface. ## Data Filter the data of the view before it is being rendered. See [Data Filtering](https://fabrikat.local/sleek/view/documentation/views/data-filtering) for detailed information on creating filters. ## Columns ### Show columns toggle Enable or disable the column visibility toggle in the table header. When enabled, users can show or hide columns directly from the table view. ### Column Labels Use **Column Labels** when the underlying field names are too technical for the people working in the view. This feature is configured in the **Data Source** settings because it belongs to the current source configuration, not to a single table tab. It does not rename the source field, change the query, or alter how SleekView stores column keys internally. That means a source key like `acf_internal_launch_date` can still be queried and saved as-is, while the UI displays a clearer label such as `Launch Date`. Typical use cases: - Replace machine-style database or meta keys with human-friendly labels - Shorten long imported column names before exposing them to editors - Keep the same wording across table, kanban, feedback, and chart tabs in one view The override is applied consistently across the table UI, including: - Table headers - Hide columns and Initially visible selectors - Sorting dropdowns - Filter builders - Export column labels If you clear a custom label, SleekView falls back to the original source label. If a preset already provides fixed column labels, this accordion is hidden because the preset owns that part of the source setup. ### Custom Columns Add computed columns to your table view. Computed columns display dynamic content constructed using row values. - **Name**: The column header text - **Content Type**: Choose between Normal Text, Link, or Custom HTML - **Content**: Use tokens like `{row.post_title}` to access row data For example, to create a column showing "View: Your Post Title", you would use: `View: {row.post_title}` ### Hide columns Select which columns should be hidden from the table by default. Users can still toggle these columns on if the "Show columns toggle" option is enabled. ### Initially visible Define which columns are visible when the table first loads. Users can toggle these columns on and off if the "Show columns toggle" option is enabled. ### Enable sorting Enable or disable column sorting functionality. When enabled, users can click column headers to sort the table data. ## Filter ### Show filter Display the advanced filter interface in the table view. This allows users to create complex filters directly from the table. ### Show search Enable the search box for quick filtering across all visible columns. ### Show custom filters Display the custom filters dropdown. Custom filters are predefined filter sets that users can quickly apply from a dropdown menu. These filters are configured in the Filter section below. ## Pagination ### Show pagination Enable or disable pagination controls. When disabled, all results are displayed on a single page. ### Show page size Display the page size selector, allowing users to choose how many items appear per page (e.g., 10, 25, 50, 100). ## Sorting ### Column to sort by Select which column should be used for initial sorting when the table loads. ### Sort order Choose whether the initial sort should be ascending or descending. ## Export ### Allow data export Enable data export functionality. When enabled, users can export the current table view (with applied filters) to CSV or XLS format. Additionally, users can select individual rows in the table and export only the selected rows, making it easy to export specific subsets of data without needing to configure additional filters. ## Inline Editing ### Allow inline editing Enable inline editing of fields directly in the table. This feature supports standard WordPress fields, ACF (Advanced Custom Fields), and MetaBox fields. When enabled, users can click on cells to edit content without opening the full post editor. ## Conditions Control the visibility of the entire table view based on user roles, environment, or other conditions. See [Conditions](https://fabrikat.local/sleek/view/documentation/views/conditions) for detailed information. --- # Views - Kanban The Kanban view provides a visual, card-based interface for managing workflow-oriented content. Cards can be dragged between columns, edited directly, and organized by any taxonomy. All settings for the Kanban view are configured through the sidebar on the right when editing a view. ## General Settings ### Name The display name for this view. This name appears in the tab navigation when multiple views are configured for the same post type. ### Type Select "Kanban" as the view type. This determines the available configuration options and how content is displayed. ### Disable view Toggle this option to temporarily disable the view from rendering in the admin. The view configuration is preserved, but it won't appear in the admin interface. ## Data Filter the data of the view before it is being rendered. See [Data Filtering](https://fabrikat.local/sleek/view/documentation/views/data-filtering) for detailed information on creating filters. ## Columns ### Taxonomy Select which taxonomy should be used for the board categories (columns). The terms of this taxonomy will become the columns in your Kanban board. For example, if you select a "Project Status" taxonomy with terms like "To Do", "In Progress", and "Done", your Kanban board will have three columns representing these statuses. ### Allow sorting Enable drag-and-drop sorting within columns. When enabled, cards can be reordered within the same column by dragging. ### Show add button Display the "Add" button in each column. When enabled, users can create new posts directly from the Kanban view by clicking the add button in any column. ### Show Uncategorized column Display a column for items that haven't been assigned to any term in the selected taxonomy. This is useful for managing unorganized content. ### Column Configuration Each column can be individually configured with custom colors and visibility settings. Expand a column to access its settings: - **Custom Color**: Set a unique color for the column to visually distinguish different workflow stages - **Visibility**: Hide specific columns from the board view ## Cards ### Taxonomy Select which taxonomy should be used for card categories. The terms of this taxonomy will be displayed as category labels on each card. This is separate from the column taxonomy and provides additional organization within cards. ### Show view Button Display a "View" button on each card. When enabled, users can click to view the post in the frontend (if applicable). Note: The view button will not be shown when using a shortcode embed. ### Show edit Button Display an "Edit" button on each card. When enabled, users can click to open a modal and edit the card content directly from the Kanban view. Note: The edit button will not be shown when using a shortcode embed. ### Show upvotes Enable the upvote system on cards. When enabled, users can upvote cards, and the vote count will be displayed. This is particularly useful for feature requests or feedback boards. ## Filter ### Show search Enable the search box for quick filtering of cards across all columns. ### Show sort options Display sorting options for the cards. Users can sort cards by date, title, votes, or other criteria. ## Comments ### Show comments Display the comments section on cards. When enabled, users can view existing comments on each card. ### Allow comments Enable users to add new comments to cards. This creates threaded discussions directly on the Kanban board. Comments support nesting, allowing for conversational threads within each card. ## Conditions Control the visibility of the entire Kanban view based on user roles, environment, or other conditions. See [Conditions](https://fabrikat.local/sleek/view/documentation/views/conditions) for detailed information. --- # Views - Feedback The Feedback view is designed for collecting and managing user feedback, feature requests, or any content that benefits from community interaction. It provides upvoting, categorization, and comment functionality. All settings for the Feedback view are configured through the sidebar on the right when editing a view. ## General Settings ### Name The display name for this view. This name appears in the tab navigation when multiple views are configured for the same post type. ### Type Select "Feedback" as the view type. This determines the available configuration options and how content is displayed. ### Disable view Toggle this option to temporarily disable the view from rendering in the admin. The view configuration is preserved, but it won't appear in the admin interface. ## Data Filter the data of the view before it is being rendered. See [Data Filtering](https://fabrikat.local/sleek/view/documentation/views/data-filtering) for detailed information on creating filters. ## Cards ### Status Select which taxonomy should be used for the card status. The terms of this taxonomy will be displayed as status labels on each feedback item (e.g., "Planned", "In Progress", "Completed"). ### Category Select which taxonomy should be used for the card category. The terms of this taxonomy will be used for categorizing feedback items (e.g., "Feature Request", "Bug Report", "Improvement"). ### Show upvotes Enable the upvote system on feedback cards. When enabled, users can upvote items, and the vote count will be displayed and can be used for sorting. ### Show edit button Display an "Edit" button on each feedback card. When enabled, users can click to open a modal and edit the feedback item directly from the view. ## Filter ### Show search Enable the search box for quick filtering of feedback items by title or content. ### Show sort options Display sorting options for the feedback list. Users can sort items by votes (most popular first), date, or other criteria. ## Submission ### Show add Button Display an "Add" button that allows users to submit new feedback items directly from the view. This is particularly useful for public-facing feedback boards. ## Comments ### Show comments Display the comments section on feedback items. When enabled, users can view existing comments on each item. ### Allow comments Enable users to add new comments to feedback items. This creates threaded discussions directly on the feedback board. Comments support nesting, allowing for conversational threads within each feedback item. ## Conditions Control the visibility of the entire Feedback view based on user roles, environment, or other conditions. See [Conditions](https://fabrikat.local/sleek/view/documentation/views/conditions) for detailed information. --- # Views - Charts The Charts view turns the current SleekView dataset into a configurable dashboard. It is designed for reporting, summaries, and visual overviews that belong beside your existing Table, Kanban, and Feedback views. Charts are configured through the sidebar on the right when editing a view. The view itself is read-only: it visualizes data, while editing, drag and drop, submissions, and upvotes remain available in the view types built for those workflows. ## General Settings ### Name The display name for this view. This name appears in the tab navigation when multiple views are configured for the same post type or data source. ### Type Select "Charts" as the view type. This determines the available configuration sections and renders the view as a dashboard of chart cards. ### Disable view Toggle this option to temporarily disable the view from rendering in the admin. The view configuration is preserved, but it will not appear in the admin interface. ## Data Filter the data before it is rendered and aggregated by the chart cards. See [Data Filtering](https://fabrikat.local/sleek/view/documentation/views/data-filtering) for detailed information on creating filters. Charts use the same data source system as the other view types. You can chart post types, custom tables, custom REST URLs, HTTP CSV/JSON/JSONC, media CSV/JSON/JSONC, WordPress-relative CSV/JSON/JSONC/SQLite files, and registered presets. ## Layout ### Minimum column width Set the minimum width for each dashboard column. SleekView uses this value to build a responsive grid, so wider values create fewer, roomier columns and smaller values create denser dashboards. Each chart card can also set its own card size: - **Auto**: follows the responsive grid - **Standard**: stays in one grid column - **Wide**: spans more horizontal space - **Full**: spans the full dashboard width ## Chart Cards Charts are managed in a repeater. Each row in the repeater becomes one card in the dashboard. Cards can be reordered with move controls and removed when they are no longer needed. ### Card title Set the title shown at the top of the chart card. ### Type Choose the chart type for the card. - **Number**: shows one aggregated value - **Area**: shows trends with optional fill, gradient, axes, and stacking - **Bar**: compares grouped values vertically or horizontally - **Line**: shows trends with straight, stepped, or curved lines - **Pie**: shows part-to-whole composition, including donut variants - **Radar**: compares grouped values across a polar grid - **Radial**: shows circular progress, share, or stacked radial values ### Variant Most chart types include variants based on shadcn chart patterns: - **Area**: default, linear, step, gradient, stacked, stacked expanded, axes - **Bar**: default, horizontal, stacked, label - **Line**: default, linear, step, dots, label - **Pie**: simple, label, label list, legend, donut, active donut, donut text - **Radar**: default, dots, lines, grid, no grid, multiple - **Radial**: simple, label, grid, text, shape, stacked Number cards only use the default variant. ## Data Mapping ### Group by column Choose the column that should become the chart categories. For example, group by `status` to show totals for Backlog, In Progress, and Done. Number cards do not use a group by column because they summarize the whole filtered dataset. ### Series column Choose an optional column for multiple series. This is available for Area, Bar, Line, and Radar charts. For example, group by month and use status as the series column to compare monthly status totals. ### Aggregation Choose how each value should be calculated. - **Count**: count rows - **Sum**: add numeric values from the value column - **Average**: average numeric values from the value column - **Minimum**: use the smallest numeric value from the value column - **Maximum**: use the largest numeric value from the value column ### Value column Choose the numeric column used by sum, average, minimum, and maximum aggregations. Count does not need a value column. ## Shared Display Settings ### Color Choose a chart color from the SleekView chart palette. Multi-series and composition charts use the palette to keep series visually distinct. ### Show tooltip Enable or disable chart tooltips. Tooltips are available for all chart cards except Number cards. ### Tooltip indicator Choose the tooltip indicator style: dot, line, dashed, or none. ### Show legend Enable or disable the legend when the chart type supports it. ### Show labels Enable or disable labels on the chart itself when the chart type supports them. ## Cartesian Settings Area, Bar, and Line charts can control the cartesian chart frame. ### Show grid Show or hide grid lines. ### Show X axis Show or hide the X axis. ### Show Y axis Show or hide the Y axis. ### Curve type Area and Line charts can choose monotone, linear, step, or natural curves. ### Stack mode Area and Bar charts can use no stacking, stacked values, or expanded stacking. ### Bar orientation Bar charts can be vertical or horizontal. ### Bar radius Set the corner radius for bar marks. ## Area and Line Settings ### Show gradient Area charts can use a gradient fill. ### Show fill Area charts can show or hide the filled area. ### Fill opacity Area and Radar charts can adjust fill opacity. ### Stroke width Area, Line, and Radar charts can adjust the stroke width. ### Show dots Line and Radar charts can show or hide point markers. ## Polar Settings Radar and Radial charts can control the polar chart frame. ### Show grid Show or hide the polar grid. ### Show radius axis Show or hide the radius axis. ### Show angle axis Radar charts can show or hide the angle axis. ### Show fill Radar charts can show or hide the filled area. ## Radius Settings Pie and Radial charts can control their circular shape. ### Inner radius Set the inner radius. Increase this value to create donut-style charts. ### Outer radius Set the outer radius. ### Start angle Set the start angle in degrees. ### End angle Set the end angle in degrees. ### Padding angle Pie charts can set spacing between slices. ### Corner radius Radial charts can set rounded segment corners. ### Center text Radial charts can show or hide centered text when the selected variant supports it. ## Conditions Control the visibility of the entire Charts view based on user roles, environment, or other conditions. See [Conditions](https://fabrikat.local/sleek/view/documentation/views/conditions) for detailed information. --- # Views - Data Sources SleekView can display data from sources beyond WordPress post types. The current source system is built around reusable external adapters, so the same view types and field mapping layer can be reused across custom tables, APIs, files, media uploads, and presets. All data source settings are configured through the sidebar on the right when editing a view, under the **Data Source** section. ## Selecting a Data Source By default, every view uses **Post Type** as its data source. To switch to a custom or external source, open the **Data Source** accordion in the sidebar and select a different type. ### Built-in source types - **Post Type** - **Custom Table** - **Custom REST URL** - **HTTP CSV** - **HTTP JSON** - **HTTP JSONC** - **Media CSV** - **Media JSON** - **Media JSONC** - **Path CSV** - **Path JSON** - **Path JSONC** - **Path SQLite** The dropdown can also include additional **custom presets** registered in PHP. Those presets appear alongside the built-in source types and can prefill data source configuration only. Depending on how they are registered, they appear under either **Integrations** or **Custom** in the dropdown. ## Understanding the Source Formats Before choosing a source type, it helps to separate the **transport** from the **format**. - **Transport** answers where the data comes from: WordPress posts, a database table, a remote URL, a media library attachment, or a file on disk. - **Format** answers how the payload is structured once SleekView receives it: CSV, JSON, JSONC, or SQLite. ### CSV CSV is a flat row-and-column format. It works well for spreadsheets, exports, and simple tabular datasets. SleekView expects the first row to contain column headers. Each later row becomes one item in the view. Delimiters are detected automatically, so comma, semicolon, tab, and pipe-separated files are all supported. ``` id,title,status,owner,priority 1,Redesign homepage,Backlog,Anna,High 2,Write launch post,In Progress,Ben,Medium 3,Fix pricing copy,Done,Clara,Low ``` Use CSV when your data is already maintained as a spreadsheet export or when you need the simplest possible interchange format. ### JSON JSON is a structured object format. It is the better choice when your data comes from APIs or when rows contain more explicit field names than a CSV header row can comfortably express. SleekView accepts either: - A top-level array of row objects - Or an object containing rows under `rows`, `data`, `posts`, or `items` It also reads optional pagination metadata from keys like `totalPosts`, `totalPages`, `postsPerPage`, and `currentPage`. ```json { "items": [ { "id": 1, "title": "Redesign homepage", "status": "Backlog", "owner": "Anna", "priority": "High" }, { "id": 2, "title": "Write launch post", "status": "In Progress", "owner": "Ben", "priority": "Medium" } ], "totalPosts": 48, "totalPages": 3, "postsPerPage": 20, "currentPage": 1 } ``` Use JSON when the source is already API-driven or when you need metadata and slightly richer structure around the rows. ### JSONC JSONC means **JSON with comments**. It is useful for hand-maintained files where you want inline notes, disabled entries, or trailing commas while editing. SleekView normalizes JSONC before decoding it, so comments and trailing commas are removed automatically on the server. ```javascript { // Roadmap items maintained by the product team "items": [ { "id": 1, "title": "Redesign homepage", "status": "Backlog", }, { "id": 2, "title": "Write launch post", "status": "In Progress", }, ], } ``` Use JSONC when the file is meant to be read and edited by humans, not just machines. ### SQLite SQLite is a file-based relational database. Instead of importing rows from a text file, SleekView can query a `.sqlite` file directly with `PDO` and `pdo_sqlite`. This is useful when your dataset is already distributed as a database file or when the data is too large or structured to manage comfortably in CSV. ### Custom REST URL Custom REST is not a file format. It is a server-side URL template for remote endpoints that should receive the current UI state, including pagination, search, and sorting. Use it when the **remote service** should decide which rows to return rather than letting SleekView fetch and slice a static file itself. ## Post Type This is the default source and the most interactive one. Post type views support WordPress-native write actions such as inline editing, kanban drag and drop, feedback submissions, upvotes, and other content mutations. Use a post type source when SleekView should manage real WordPress content. Post types are currently the only source with create, update, delete, drag and drop, submission, and upvote handlers implemented in SleekView. ## Custom Table Query any WordPress database table directly. This is the simplest option when you already have structured data in MySQL and want to render it as a table, kanban board, feedback list, or chart dashboard. ### When to use it Choose **Custom Table** when: - Your data already lives in a WordPress database table - You want the fastest path to a read-only custom source - You do not need an HTTP layer, file import step, or custom remote auth flow ### Configuration - **Table**: Pick one of the discovered database tables from the dropdown - **Field Mapping**: Map table columns to SleekView fields like title, content, date, and id Custom tables are read-only from SleekView. Search, filtering, sorting, pagination, and export still work through the shared query engine. ## Custom REST URL Use a custom REST endpoint when the remote service needs to handle pagination, search, ordering, or custom authentication logic on its side. ### When to use it Choose **Custom REST URL** when: - The API already supports server-side pagination and search - You need custom authorization or signed requests through a preset - The endpoint should respond differently depending on the current UI state ### Configuration - **URL**: Enter the full endpoint URL in the textarea - **Supported tags**: `{pageNumber}`, `{perPage}`, `{search}`, `{orderBy}`, `{order}` - **Field Mapping**: Map returned fields to the view These tags are replaced server-side before the request is sent. This lets the current UI state drive the remote query without exposing internal implementation details to the browser. ### Example URL template ``` https://example.com/api/tasks?page={pageNumber}&per_page={perPage}&search={search}&orderby={orderBy}&order={order} ``` ### Example response ```json { "items": [ { "id": 21, "title": "Fix checkout copy", "status": "Review", "owner": "Julia" } ], "totalPosts": 87, "totalPages": 5, "postsPerPage": 20, "currentPage": 2 } ``` If your API returns this metadata, SleekView can keep the current page state in sync with the remote source. ## HTTP CSV, JSON, and JSONC These sources fetch remote files over HTTP on each query. SleekView parses the response server-side and still returns paginated view data to the browser. ### HTTP CSV Use this when the remote source publishes a CSV file at a stable URL. Typical use cases: - A spreadsheet export published from another system - A generated reporting feed - A static file in cloud storage or a CDN ### Example URL ``` https://example.com/exports/projects.csv ``` ### HTTP JSON Use this when the endpoint returns standard JSON and you do not need comment support. Typical use cases: - Public APIs - Internal endpoints returning row arrays - Remote datasets with pagination metadata ### Example JSON payload ```json [ { "id": 1, "title": "Redesign homepage", "status": "Backlog", "owner": "Anna" }, { "id": 2, "title": "Write launch post", "status": "In Progress", "owner": "Ben" } ] ``` ### HTTP JSONC Use this when the remote file or endpoint contains JSON with comments or trailing commas. This is less common for formal APIs, but useful for hand-maintained config-style files exposed over HTTP. ### Shared configuration - **URL**: The full remote URL to fetch - **Field Mapping**: Map the parsed columns or keys to SleekView fields ## Media CSV, JSON, and JSONC These sources use files from the WordPress media library. SleekView stores the selected attachment ID and parses the file server-side. ### When to use them Choose a media source when editors should manage the file directly in WordPress instead of typing a URL or filesystem path. ### Configuration - **Media File**: Pick a CSV, JSON, or JSONC file from the media library - **Field Mapping**: Map the parsed columns or keys to SleekView fields ### Practical difference from HTTP and Path sources - **HTTP sources**: best when the file lives on another server or needs a public URL - **Path sources**: best when developers manage files on disk - **Media sources**: best when site editors should upload and replace files in WordPress If you need comment-enabled JSON from the media library, use **Media JSONC**. For remote or filesystem variants, use **HTTP JSONC** or **Path JSONC**. ## Path CSV, JSON, JSONC, and SQLite These sources read files directly from the server filesystem. Paths are resolved relative to the WordPress root, for example: - `/wp-content/uploads/imports/data.csv` - `/wp-content/uploads/imports/data.json` - `/wp-content/uploads/imports/data.jsonc` - `/wp-content/uploads/imports/data.sqlite` Choose a path source when the file should live inside the WordPress filesystem and does not need to be selected through the media library. ### Path CSV Use this for CSV files placed on disk under the WordPress root. ### Path JSON Use this for standard JSON files placed on disk under the WordPress root. ### Path JSONC Use this for hand-maintained JSONC files on disk, especially when developers or site owners want inline comments and trailing commas during editing. ### Example JSONC path and file ``` /wp-content/uploads/imports/product-roadmap.jsonc ``` ```javascript { // Product roadmap grouped by status "items": [ { "id": 101, "title": "Usage analytics", "status": "Planned", } ], } ``` ### Path SQLite Query a SQLite database file via `PDO` and `pdo_sqlite`. This is the best path-based option when the source is already relational data or when a single file should contain a large structured dataset. #### Additional SQLite configuration - **Path**: The WordPress-relative path to the `.sqlite` file - **SQLite Table**: Enter the table name when the database contains multiple tables If the SQLite file contains exactly one table, SleekView can resolve it automatically. ## Custom Source Presets Developers can register reusable source presets with the `sleekView/dataSourcePresets` PHP filter. Presets are useful when you want editors to start from a known source setup instead of configuring every field manually. Typical examples include: - A custom REST endpoint with private authorization headers - A standard HTTP JSON source with predefined field mapping - A Media JSONC source that always points to a specific attachment - A WooCommerce lookup table exposed as a ready-made custom table preset A preset can define: - **key**: Stable internal identifier used as `presetKey` - **group**: Optional dropdown group, currently `integrations` or `custom` - **label**: The text shown in the dropdown - **type**: Which built-in source type the preset is based on - **dataSource**: Public source settings stored with the view - **fetch**: Optional server-side request settings for remote sources Preset selection only updates the data source. It does not change the post type, tab setup, kanban settings, feedback settings, or any other view configuration. ### Preset API The filter receives the current preset list and expects the same structure back. Each preset is an array with the following shape: ```php [ 'key' => 'product-api', 'group' => 'custom', 'label' => 'Product API', 'type' => 'customRest', 'dataSource' => [ // required, saved with the view 'url' => 'https://example.com/api/products?page={pageNumber}&per_page={perPage}&search={search}', 'fieldMapping' => [ 'id' => 'id', 'title' => 'title', 'content' => 'description', 'date' => 'createdAt', ], 'columnLabels' => [ 'id' => 'Product ID', 'title' => 'Product Name', 'description' => 'Summary', 'createdAt' => 'Created', ], ], 'fetch' => [ // optional, server-side only 'headers' => [ 'Authorization' => 'Bearer secret-token', ], 'timeout' => 20, 'redirection' => 3, ], ] ``` `dataSource` is the public part of the preset. It is applied to the view and stored like any other data source configuration. This is also where locked field mappings and locked column labels belong. `fetch` is the server-only request layer for remote sources. It is not exposed to the browser in the localized preset list, which makes it the correct place for authorization headers, stricter timeout settings, or redirect limits. If a preset provides `dataSource.fieldMapping`, the **Field Mapping** accordion is hidden. If it provides `dataSource.columnLabels`, the **Column Labels** accordion is hidden as well. Editors still use the configured mapping and labels, but those parts of the source are owned by the preset. ### Example preset: Custom REST with private headers ```php add_filter('sleekView/dataSourcePresets', function ($presets) { $presets[] = [ 'key' => 'product-api', 'group' => 'custom', 'label' => 'Product API', 'type' => 'customRest', 'dataSource' => [ 'url' => 'https://example.com/api/products?page={pageNumber}&per_page={perPage}&search={search}', 'fieldMapping' => [ 'id' => 'id', 'title' => 'title', 'content' => 'description', 'date' => 'createdAt', ], ], 'fetch' => [ 'headers' => [ 'Authorization' => 'Bearer secret-token', ], 'timeout' => 20, ], ]; return $presets; }); ``` This keeps private credentials on the server while still giving editors a clean source option in the dropdown. Editors only see the preset label. The actual request headers stay in PHP. ### Example preset: WooCommerce lookup table SleekView itself uses the same preset API to register built-in WooCommerce presets when WooCommerce is installed. The pattern is intentionally simple: it is just a `customTable` preset with a fixed table, field mapping, and column labels. ```php add_filter('sleekView/dataSourcePresets', function ($presets) { if (!class_exists('WooCommerce')) { return $presets; } global $wpdb; $presets[] = [ 'key' => 'woocommerce-order-stats', 'group' => 'integrations', 'label' => 'WooCommerce: Order Stats', 'type' => 'customTable', 'dataSource' => [ 'tableName' => $wpdb->prefix . 'wc_order_stats', 'fieldMapping' => [ 'id' => 'order_id', 'title' => 'order_id', 'content' => 'status', 'date' => 'date_created', ], 'columnLabels' => [ 'order_id' => 'Order ID', 'date_created' => 'Created', 'total_sales' => 'Total Sales', 'customer_id' => 'Customer ID', 'status' => 'Status', ], ], ]; return $presets; }); ``` This is the same as manually selecting **Custom Table**, choosing `wp_wc_order_stats`, mapping the fields, and renaming the columns. The preset simply packages that setup into one dropdown option. ## Common Settings The following behavior applies to all non-post-type sources. ### Field Mapping Map external columns or keys to the fields SleekView expects for rendering. These mappings are shared across table, kanban, feedback, and chart views. - **ID**: Stable identifier for the row - **Title**: Main label shown in cards and tables - **Content**: Body or description content - **Date**: Date used for display and date-based sorting Without field mapping, SleekView can still read the raw dataset, but the view types will not know which fields should behave like labels, body text, and dates. Built-in custom sources expose field mapping in the sidebar. Preset sources can ship with a fixed mapping and hide that accordion from editors entirely. ### Column Labels Field mapping answers which source keys should behave like title, content, date, and id. It does not rename those keys for editors. If a source exposes technical column names such as `meta_release_target_q3`, use the **Column Labels** accordion in the data source settings to define human-friendly display names. These labels are stored with the current view's data source, so they apply consistently across table, kanban, feedback, and chart tabs that use the same source inside that view. Different views can still use different wording for the same underlying dataset. Preset sources can ship with fixed column labels. When they do, the **Column Labels** accordion is hidden because the preset owns that part of the configuration. ### View Support All custom sources can be rendered in the same four view types: - **Table** - **Kanban** - **Feedback** - **Charts** Once field mapping is in place, the same dataset can be presented in multiple ways without changing the underlying source. ### Server-Side Querying Search, filters, sorting, pagination, and export are all handled by SleekView on the server side. This keeps large datasets out of the browser and gives every custom source the same query model. In practice this means: - The browser does not need the full dataset to render a page - Remote files can still behave like pageable data sources - Custom REST endpoints can react to search, page, and order parameters - Table export respects the current view state ### Interaction Limits External and custom sources are intentionally read-only inside SleekView. They render the same layouts, but write actions remain post-type only because those write handlers are currently implemented only for post type sources. - No inline editing - No kanban drag and drop - No feedback submission or feedback editing - No upvoting or popularity-based feedback sorting This keeps the behavior predictable: every source can share the same rendering, querying, and mapping layer, but only post types expose mutation features in the UI. --- # Admin Pages Custom admin pages allow you to compose multiple views together on a single admin screen. This is composition at its finest – combine different post types, mix multiple views, and create personalized dashboards that match your workflow perfectly. ![Custom admin pages screenshot](https://fabrikat.local/sleek/wp-content/themes/fabrikat/src/assets/sleek/images/view/home/admin-page.png) ## What Makes Admin Pages Special Unlike standard views which are attached to a specific post type, admin pages are standalone pages in the WordPress admin where you can combine any views you want. The key advantage is that **everything stays fully interactive** – you can still drag, drop, edit, and manage content directly, just as you would in the individual views. ## Creating an Admin Page To create a new admin page, navigate to the SleekView settings and create a new admin page. The configuration sidebar on the right contains all settings for the admin page: ### General Settings #### Name The internal name for the admin page. This is used for identification in the SleekView settings. #### Menu Title The title that appears in the WordPress admin menu sidebar. This is what users will see when navigating your admin area. #### Position The position of the admin page in the WordPress admin menu. Lower numbers appear higher in the menu. Common values: - **5**: Below Dashboard - **10**: Below Posts - **20**: Below Pages - **25**: Below Comments - **29**: Above custom post types (typical placement) #### Icon Choose an icon for the admin page menu item. SleekView uses Ionicons for consistent styling across the admin interface. #### Disable admin page Toggle this option to temporarily disable the admin page from appearing in the admin menu. The configuration is preserved but the page won't be accessible. ## Views Section This is where you compose your admin page by adding multiple views. Each view is displayed as a separate section on the admin page. ### Adding Views Click "Add View" to add a new view to the admin page. Each added view appears as a collapsible section in the Views accordion. To configure an individual view within the admin page, click the cog icon on that view's section. This opens the view-specific settings: #### Name An optional custom name to override the view's default name. This is useful when you want to display the same view multiple times with different filtering or when you want a more descriptive name in this context. #### View Select which view to display in this section. You can choose from any of your configured views, regardless of which post type they're attached to. ### View Organization Views are displayed on the admin page in the order they appear in the Views section. Use the navigation arrows to: - Reorder views (move up/down) - Delete views from the admin page ## Use Cases Custom admin pages excel in scenarios where you need to monitor or manage multiple types of content simultaneously: ### Project Management Dashboard Combine views for: - Tasks (Kanban view) - Client communications (Table view) - Project milestones (Feedback view) ### Content Operations Hub Combine views for: - Pending articles (Table view) - Editorial calendar (Kanban view) - Reader feedback (Feedback view) ### Support Center Combine views for: - Active tickets (Table view) - Ticket workflow (Kanban view) - Feature requests (Feedback view) ### Multi-Product Roadmap Combine views for different products: - Product A features (Kanban view) - Product B features (Kanban view) - Product C features (Kanban view) ## Conditions Like individual views, admin pages support conditions to control visibility. Use conditions to: - Restrict admin pages to specific user roles - Show different pages to different user groups - Create role-specific dashboards See [Conditions](https://fabrikat.local/sleek/view/documentation/views/conditions) for detailed information on setting up conditions. ## Best Practices 1. **Logical Grouping**: Group related views together on the same admin page 2. **Descriptive Names**: Use clear menu titles that indicate the page's purpose 3. **Strategic Positioning**: Place frequently used admin pages higher in the menu 4. **Appropriate Icons**: Choose icons that visually represent the page's content 5. **Role-Based Pages**: Create different admin pages for different user roles using conditions 6. **Start Simple**: Begin with 2-3 views and expand as needed ## Limitations While admin pages are incredibly powerful, keep in mind: - Admin pages only work in the WordPress admin area (they cannot be embedded via shortcode) - Each view on an admin page uses its own configuration and filters - Performance may be impacted when displaying many large views on a single page Custom admin pages transform how you work with WordPress content, bringing everything you need into a single, focused workspace. --- # AI - API Keys To unlock SleekView's AI capabilities, you'll need to provide your own API keys from one or more AI providers. This approach gives you complete control over your AI usage while ensuring your data remains private. Rather than routing through SleekView's servers, your WordPress site communicates directly with the AI providers, keeping your code and conversations secure. The setup process involves obtaining API keys from your chosen providers and configuring them within SleekView. Each provider offers different models with unique strengths, so you might choose to set up multiple providers to access the best model for each type of task. ## Understanding API key requirements API keys are essentially passwords that allow SleekView to authenticate with AI providers on your behalf. When you make a request through SleekView, it uses your API key to access the AI models directly. This means you're billed directly by the provider based on your actual usage, giving you transparent cost control. The benefits of this approach include: - **Complete data ownership** - Your conversations never pass through third-party servers - **Transparent billing** - You see exactly what you're paying for with each provider - **Model flexibility** - Access to different models optimized for various tasks - **Privacy control** - Your code and conversations remain between you and the AI provider ## OpenAI OpenAI provides some of the most popular models for code generation, including GPT-4 and its variants. These models excel at understanding context and generating high-quality WordPress code. 1. **Create or access your account** - Visit the [OpenAI Platform](https://platform.openai.com/) - Sign up for a new account or log into your existing one 2. **Generate your API key** - Navigate to [https://platform.openai.com/account/api-keys](https://platform.openai.com/account/api-keys) - Click "Create new secret key" - **Copy the key immediately** - it won't be shown again - Store it securely for SleekView configuration 3. **Add account funding** - Visit the [Billing Overview](https://platform.openai.com/account/billing/overview) - Add credit to your account using "Add to credit balance" - OpenAI operates on pay-per-use, so you only pay for what you use ## Anthropic Anthropic's Claude models are particularly strong at understanding complex codebases and providing detailed explanations. These models often excel at debugging and code review tasks, making them valuable for maintaining and improving existing code. 1. **Set up your Anthropic account** - Go to the [Anthropic Console](https://console.anthropic.com/) - Create an account or log into your existing one 2. **Create your API key** - Navigate to [https://console.anthropic.com/settings/keys](https://console.anthropic.com/settings/keys) - Click "Create Key" to generate a new API key - Copy and store the key securely 3. **Fund your account** - Visit [Billing Settings](https://console.anthropic.com/settings/billing) - Add funds to enable API usage - Review their pricing structure for cost planning ## Google Google's Gemini models offer competitive performance and often have different pricing structures that might be more cost-effective for certain types of usage. They're particularly strong at understanding and generating code with large context windows. 1. **Access Google AI Studio** - Visit [Google AI Studio](https://aistudio.google.com/apikey) - Sign in with your Google account 2. **Generate your API key** - Click "Create API key" to generate a new key - Copy the key and keep it private and secure 3. **Configure in SleekView** - The setup process is streamlined with Google's integrated approach - You can quickly get your API key working with SleekView's latest Gemini model support ## OpenRouter OpenRouter is unique because it provides access to dozens of different AI models through a single API. This gives you access to specialized coding models, the latest releases from various providers, and often more competitive pricing. 1. **Create your OpenRouter account** - Sign up at [OpenRouter](https://openrouter.ai/) using your preferred method - Choose from various authentication options 2. **Generate your API key** - Visit [OpenRouter Settings](https://openrouter.ai/settings/keys) - Click "Create Key" to generate your API key - Store the key securely 3. **Add credits to your account** - Use OpenRouter's billing system to add credits - These credits work across all supported models - Take advantage of competitive pricing across multiple providers The advantage of OpenRouter is flexibility—you can experiment with different models for different tasks without managing multiple separate accounts and billing relationships. ## Configuring SleekView Once you have your API keys, setting them up in SleekView is straightforward and secure. 1. **Access SleekView settings** - In your WordPress admin, navigate to the SleekView section - Look for "Settings" or "AI Configuration" 2. **Enter your API keys** - Find the API Keys section with input fields for each provider: - **OpenAI API Key** - **Anthropic API Key** - **Google API Key** - **OpenRouter API Key** - Paste your keys into the appropriate fields 3. **Save your configuration** - Click the "Save" button next to each field after entering the key - SleekView automatically validates each key - Verify that all keys are working correctly Your API keys are stored encrypted in your WordPress database, providing security while keeping them readily available for AI requests. ## Security and privacy considerations The security model of SleekView's AI integration is designed around privacy and control. Understanding how your data flows helps you make informed decisions about using AI assistance. ### Data flow and privacy **Direct Communication Model** - Requests go directly from your WordPress server to the AI provider - SleekView never sees your conversations, code, or API keys - You maintain complete control over your data and usage patterns **Local Storage Security** - API keys are encrypted when stored in your WordPress database - SleekView follows WordPress security best practices - Keys are only accessible to your WordPress installation **Cost and Usage Control** - You can review usage patterns directly with each provider - Monitor costs in real-time through provider dashboards - No markup or hidden fees from SleekView ## Getting started with AI assistance With your API keys configured, SleekView's AI features become available throughout the interface. The AI understands WordPress best practices and can provide intelligent assistance tailored to your specific needs. ### Initial steps 1. **Start with simple requests** to get familiar with how the AI responds 2. **Experiment with different providers** to understand their strengths 3. **Gradually work up to more complex tasks** as you become comfortable 4. **Monitor your usage** through each provider's dashboard The AI is designed to be a collaborative partner in your WordPress workflow, helping you achieve your goals more efficiently while following best practices. --- # AI - Chat SleekView's AI chat is a fully agentic assistant that understands your project structure and can perform complex operations automatically. Unlike simple chatbots that just answer questions, this AI can analyze your work, create complete solutions, and call tools to help you achieve your goals efficiently. ## Understanding the agentic approach The term "agentic" means the AI can take autonomous actions on your behalf. When you ask for something, it doesn't just provide advice—it actually performs the work. This intelligent system can analyze your existing work, understand your project structure, and make informed decisions about how to implement your requests. ### Understanding your views and admin pages SleekView includes two specialized AI agents that understand your content structure and can configure views on your behalf. The View Agent works with individual views (Table, Kanban, Feedback, Charts), while the Admin Page Agent helps compose multiple views into custom admin pages. Both agents can read your existing configurations, understand your post types, taxonomies, and fields, and make precise adjustments to match your workflow needs. ### What the AI can do The agents can create new views from scratch, configure existing views with specific filtering and display options, set up conditions for role-based access control, organize columns and cards with custom taxonomies, configure chart cards for reporting, and compose admin pages that combine multiple views. Ask for complete setups like "create a Kanban board for my projects post type using the status taxonomy for columns" or make targeted adjustments like "add a chart dashboard grouped by status for the last 30 days." ## Tips for better results Be specific about what you want to accomplish and which view or admin page you're working with. For example: "add a condition to show the edit button only to administrators," or "create a Table view for posts with columns for title, author, and publish date." Share relevant details about your content structure— post types, taxonomies, custom fields—so the agent can configure views accurately. The agents understand WordPress conventions and will ask clarifying questions when needed. ## When something needs adjustment If a view isn't showing the right content, describe what should appear and the agent will adjust the data filtering or conditions. When layout or organization feels off, ask for specific changes to column visibility, sorting, or card configurations. If role-based access isn't working as expected, describe who should see what and the agent will update the conditions. The agents can also help troubleshoot shortcode embeds and explain why certain configurations behave differently in admin versus frontend contexts. ## How configurations are applied The agents explain what they're configuring before making changes. You'll see which settings are being adjusted, why those changes support your goal, and any relevant notes about how the configuration will behave in different contexts (admin versus frontend). This transparency helps you understand your views and makes it easy to refine configurations over time. ## Common configuration tasks SleekView's AI agents excel at typical view management scenarios. Create Kanban boards for project tracking, set up data tables with custom filtering for content management, configure feedback views for public roadmaps, compose admin pages that combine multiple views into dashboards, add Charts views for reporting, add role-based conditions for different user experiences, and set up frontend embeds with appropriate visibility controls. Describe your use case and the agents will recommend the right view type and configuration approach. ## Best practices Start by describing your content structure and what you want to accomplish. Mention post types, taxonomies, and any custom fields relevant to the view. Work incrementally—set up basic view configuration first, then add filtering, conditions, and advanced features. Test views in both admin and frontend contexts if you plan to use shortcodes. When working with admin pages, consider which views logically belong together on the same dashboard. The agents can help with all of this, so don't hesitate to ask questions about the best approach for your specific scenario. ---