sleek logo sleek ai/ logo sleek byte/ logo sleek motion/ logo sleek pixel/ logo sleek view/ logo

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
  
                    

                Copy

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.

            {
      "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
    }
  
                    

                Copy

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.

            {
      // Roadmap items maintained by the product team
      "items": [
        {
          "id": 1,
          "title": "Redesign homepage",
          "status": "Backlog",
        },
        {
          "id": 2,
          "title": "Write launch post",
          "status": "In Progress",
        },
      ],
    }
  
                    

                Copy

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, or feedback list.

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}
  
                    

                Copy

Example response

            {
      "items": [
        {
          "id": 21,
          "title": "Fix checkout copy",
          "status": "Review",
          "owner": "Julia"
        }
      ],
      "totalPosts": 87,
      "totalPages": 5,
      "postsPerPage": 20,
      "currentPage": 2
    }
  
                    

                Copy

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
  
                    

                Copy

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

            [
      {
        "id": 1,
        "title": "Redesign homepage",
        "status": "Backlog",
        "owner": "Anna"
      },
      {
        "id": 2,
        "title": "Write launch post",
        "status": "In Progress",
        "owner": "Ben"
      }
    ]
  
                    

                Copy

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
  
                    

                Copy
                
                                 
            

            
            {
      // Product roadmap grouped by status
      "items": [
        {
          "id": 101,
          "title": "Usage analytics",
          "status": "Planned",
        }
      ],
    }
  
                    

                Copy

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:

            [
        '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,
        ],
    ]
  
                    

                Copy

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

            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;
    });
  
                    

                Copy

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.

            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;
    });
  
                    

                Copy

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, and feedback 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 three 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, and feedback 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 three view types:

  • Table
  • Kanban
  • Feedback

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.