An example of using Custom Publish forms powered by a third party app or API.
This repo is organized into two directories:
statamic
holds the Statamic sitelaravel
holds the Laravel app that will be acting as the API
The Laravel site contains a ProductController that contains the basic read, storing, and updating logic. The /product*
CSRF verification has been disabled just to make things simpler.
Make sure you can access both sites from their own URLs.
In the .env
file for the Statamic site, add the Laravel site's URL.
LARAVEL_URL=http://the-laravel-app.test
Create a database for the Laravel app and add the credentials to its .env
file.
DB_HOST=localhost
DB_DATABASE=statamic-api
DB_USERNAME=root
DB_PASSWORD=
We have included a migration in this repo, run it.
php artisan migrate
We have a Listener file that takes care of adding an item to the navigation. Click the Products
item in the sidebar to view the listing.
When creating or editing a product, the publish component will be rendered according to the provided product fieldset.
To add more fields, you should create a migration (or update the original one) in the Laravel app to add the columns to the table, and also add fields to the fieldset so they are rendered on the publish page.
This repo assumes you will be doing the validation on the Laravel side.
This repo passes the validation errors back into the ProductRepository class. It prefixes all the fields with a fields.
string. This is because the Publish component will bring the first erroring field into focus and is expecting them all to be nested within fields
.
The /products
route is a page that loads a template containing a simple custom tag.
The /products/{slug}
route is a wildcard route that loads a template with another simple custom tag.