Skip to content

dlsu-lscs/lscs-cms

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

44 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Logo LSCS Headless Content Management System


Table of Contents

  1. Development
  1. Collections
  1. REST Endpoints

Development

  1. First clone the repo if you have not done so already

  2. cd my-project && cp .env.example .env to copy the example environment variables. You'll need to add the DATABASE_URI from your Cloud project to your .env if you want to use S3 storage and the PostgreSQL database that was created for you.

  3. pnpm install && pnpm dev to install dependencies and start the dev server

  4. open http://localhost:3000 to open the app in your browser

That's it! Changes made in ./src will be reflected in your app. Follow the on-screen instructions to login and create your first admin user. Then check out Production once you're ready to build and serve your app, and Deployment when you're ready to go live.

Docker (Optional)

If you prefer to use Docker for local development instead of a local PostgreSQL instance, the provided docker-compose.yml file can be used.

To do so, follow these steps:

  • Modify the DATABASE_URI in your .env file to URI of your selected DB
  • Modify the docker-compose.yml file's DATABASE_URI to match the above <dbname>
  • Run docker-compose up to start the database, optionally pass -d to run in the background.

Collections

Collections are the defined entities of your CMS. See the Collections docs for details on how to extend this functionality.

Default Collections

  • Users (Authentication)

    Users are auth-enabled collections that have access to the admin panel.

    For additional help, see the official Auth Example or the Authentication docs.

  • Media

    This is the uploads enabled collection. It features pre-configured sizes, focal point and manual resizing to help you manage your pictures.


REST Endpoints

Payload automatically configures REST endpoints for the defined collections

For example the User Collection will have the /api/users for the GET request of all users and /api/users/[id] will query specific users based on the id.

Autogenerated REST Endpoints

Payload CMS automatically generates RESTful API endpoints for each collection you define. These endpoints allow you to interact with your data using standard HTTP methods such as GET, POST, PUT, and DELETE.

How it works:

  • Each collection (e.g., Users, Media, Posts) gets its own set of endpoints under /api/<collection-slug>.
  • You can perform CRUD operations (Create, Read, Update, Delete) on your collections via these endpoints.
  • Authentication and access control are handled automatically for protected collections.

Examples:

  • GET /api/users β€” Retrieve a list of all users
  • GET /api/users/[id] β€” Retrieve a specific user by their unique ID
  • POST /api/users β€” Create a new user (requires appropriate permissions)
  • PUT /api/users/[id] β€” Update an existing user
  • DELETE /api/users/[id] β€” Delete a user

You can use similar endpoints for other collections, such as Media or Posts:

  • GET /api/media β€” List all media files
  • GET /api/posts β€” List all posts

For more details, see the Payload REST API documentation.

Query Parameters

Payload CMS supports powerful query parameters that allow you to add filtering, sorting, pagination, and other logic to your REST API requests. These parameters transform simple GET requests into sophisticated database queries.

Filtering with where

Use the where parameter to filter results based on field values:

GET /api/users?where[status][equals]=active
GET /api/posts?where[title][contains]=payload
GET /api/media?where[mimeType][like]=image%

Common operators:

  • equals - Exact match
  • not_equals - Not equal to
  • contains - Text contains substring
  • like - SQL LIKE pattern matching
  • in - Value is in array
  • not_in - Value is not in array
  • greater_than - Numeric/date comparison
  • less_than - Numeric/date comparison
  • exists - Field exists (true/false)

Sorting with sort

Sort results by one or more fields:

GET /api/posts?sort=createdAt          # Ascending
GET /api/posts?sort=-createdAt         # Descending (prefix with -)
GET /api/users?sort=lastName,firstName # Multiple fields

Pagination with limit and page

Control the number of results and pagination:

GET /api/posts?limit=10                # Limit to 10 results
GET /api/posts?limit=10&page=2         # Second page of 10 results

Population with depth

Control how deeply related documents are populated:

GET /api/posts?depth=1                 # Populate one level deep
GET /api/posts?depth=0                 # No population (IDs only)

Field Selection

Select specific fields to return:

GET /api/users?select=name,email       # Only return name and email fields

Complex Query Example

Combine multiple parameters for sophisticated queries:

GET /api/posts?where[status][equals]=published&where[author][in]=123,456&sort=-createdAt&limit=5&depth=1

This query finds:

  • Posts with status "published"
  • By authors with IDs 123 or 456
  • Sorted by creation date (newest first)
  • Limited to 5 results
  • With author details populated

For complete query syntax and advanced operators, see the Payload Queries documentation.

Custom Endpoints

API Endpoints with custom business logic needs to be implemented manually. Contact the development team for your request to be accomodated.

About

A Headless CMS infrastructure using Payload CMS

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors