statamic / cms

The core Laravel CMS Composer package

About Statamic

Statamic is the flat-first, Laravel + Git powered CMS designed for building beautiful, easy to manage websites.

Note: This repository contains the code for the core CMS package. To start your own website project with Statamic, visit the Statamic application repository.

Learning Statamic

Statamic has extensive documentation. We dedicate a significant amount of time and energy every day to improving them, so if something is unclear, feel free to open issues for anything you find confusing or incomplete. We are happy to consider anything you feel will make the docs and CMS better.

Support

We provide official developer support on Statamic Pro projects. Community-driven support is available on GitHub Discussions and in Discord.

Contributing

Thank you for considering contributing to Statamic! We simply ask that you review the contribution guide before you open issues or send pull requests.

Code of Conduct

In order to ensure that the Statamic community is welcoming to all and generally a rad place to belong, please review and abide by the Code of Conduct.

Important Links

• Statamic Main Site
• Statamic Documentation
• Statamic Application Repo
• Statamic Migrator
• Statamic Discord

cms's Issues

Add YAML fences to markdown files

v2 removed fences from markdown files when there was no content key.
This was mainly due to YAML::dump() being used in the same way for a .yaml or .md file. We didn't want the fences in a .yaml file.

However, no fences in a markdown file means no syntax highlighting. Sucky. Bring it back.

#MakeMarkdownGreatAgain

Separate content directories for locales/sites

Allow multiple locales/sites to have their own page structures, entries, etc.

They could be be related by ID.

Antlers should not be responsible for extracting front matter

https://github.com/statamic/three-cms/blob/master/app/View/Antlers/Engine.php#L73-L83

Antlers is just a template parser. It shouldn't be concerned with data wangjangling.

Upgrade to Symfony YAML

Remove Superfluous Features

• Fieldset "Create Title"
• Global Redactor settings (in favor of reusable field configurations in "blueprints")
• Customizable Theme defaults (like default entry fieldset, default taxonomy term fieldset...)

Pagination

We use a paginator presenter to generate the array necessary for pagination. They are used in the CP and in templates.

Newer versions of Laravel changed how pagination works. No longer uses presenters, instead it uses views which would just return html.

We need to work out a way to get our arrays back.

Currently disabled in:

• Entry listing
• Term listing
• Asset listing

Currently broken in:

• Collection tag with pagination param

JS implementation of new translations

Related to #14 we need a way to translate in JS using the new method.

Theme macros location

In v2 they were in site/themes/yourtheme/settings/macros.yaml

Now they are in resources/macros.yaml

Is that good or should they be moved?

Addons are installed and managed via Composer

Extension files can be located in the App directory

To extend Statamic in v2 you needed to create an addon or make "site helpers".

In v3, it makes sense to just put stuff in your app directory like you would with Laravel.

We should just allow users to place these files in an appropriate spot.

/
|-- app/
|    |-- Tags/
|    |     |-- Foo.php    -> {{ foo }}, {{ foo:bar }}, etc
|    |     |-- Bar.php    -> {{ bar }}, {{ bar:baz }}, etc
|    |-- Modifiers/
|          |-- Foo.php    -> {{ var | foo }}
|          |-- Bar.php    -> {{ var | bar }}
|    |-- Fieldtypes/
|          |-- Example.php
|    |-- Filters/
|          |-- Example.php
|    |-- Widgets/
|          |-- Example.php
|-- public/
|-- artisan

• Tags
• Modifiers
• Fieldtypes
• Filters
• Widget

We dont need to port these since they are just Laravel things now:

• Service Provider
• Controller
• Command
• Scheduled Task
• Event Listener

Improve Database Users

v2 requires you to flick a switch on the Statamic side of things which uses its own User model.
It was done this way to adapt to our "User" class.

A better solution would probably be to reverse the logic.
Use the built-in Laravel authentication system, with an App\User and maybe provide a trait people can throw in to make it compatible with our User class.

Add tag bindings into addons

We jammed some aliases into core to make some addons work in v2.

We manually bind the tags and any aliases in v3, so we should put them in the right place now.

• var to Variables in the var addon.
• page and entry to Crud in workshop.

Trim down unnecessary <head> and script stuff outside the CP

Until you're logged in we don't need markdownHardWrap, fieldtype js, and all that jazz. Let's keep it lean and mean.

Break apart the Parse class

It is currently responsible for parsing Antlers templates, loops, yaml, front-matter, and env vars. These bits should probably be (and in some cases already are and just aliased) in their respective classes. With friends.

Convert API classes into Facades

Right now they are classes full of static methods.

Would be much better for testability if they are Facades.

Remove driver logic from assets

In v2, we had different logic depending on the driver (eg local vs s3)

Things like making container URLs relative if it's a local driver.

In v3, we're just delegating to a filesystem disk. Our driver logic should be thrown out and let the disk do all the work.

• Do the replacements
• Write tests
• ItemNormalizerTest is specifying an s3 driver just to get things to work until this is done. Undo those.

Standardize Validation Formatting

Laravel 5.5 introduced a more standardized way to format validation exception responses.

{
    "message": "The given data was invalid.",
    "errors": {
        "field-1": [
            "Error 1",
            "Error 2"
        ],
        "field-2": [
            "Error 1",
            "Error 2"
        ],
    }
}

The docs say that you can override how they are formatted in a single place, but we've been a little inconsistent anyway. We should just refactor the bits to accept the "standard" responses.

Allow additional fields to be automatically markdown-ified

When you use a .md filename, the content field gets converted to markdown automatically in your templates (or .textile files to textile). Other fields remain raw, so you have to do {{ other_field | markdown }}.

It would be cool if you could specify somewhere that other fields should also be converted.

Store collection and taxonomy routes in their files

If you programmatically modify a collection's route, it will actually re-save the config file.
This was okay when we used YAML files, but now that we're using PHP files, all the comments and formatting will be lost. It will be quite sad.

So, I think the route should be moved into the folder.yaml

# content/collections/blog/folder.yaml
title: Blog
template: blog/post
route: /blog/{slug}  # here

I think it makes more sense to be there anyway.

Replace our custom config with native Laravel config

What makes sense to go in a php config file, should.

Ability to upgrade Statamic in the CP via composer

Catch RedirectExceptions and return a redirect

Related to statamic/v2-hub#1525

We might run into more issues with leaving the exception handler to handle redirects. If we perform the redirect in the controller it should be fine.

Remove deprecations

Replace the multiple themes concept with a typical resources directory

• All views go in views instead of in templates, layouts, and partials
• Add an option to use v2 style templates, layouts, and `partials for BC
• Theme tags read timestamps from public directory for cache busting
• Theme tags that defaulted to theme name in filenames should just use app.
• Versioned filenames should read from mix-manifest.json and also rev-manifest.json for BC
• Partial and Theme:partial tags should be able to look in views or partials directories

Remove Updater from CP

It should work the same except for the actual updating part. Instead, we should display instructions on how to do it with Composer.

Temporarily, at least.

Live Preview

Since it hits the actual URL, if static caching is enabled, it shows the cached page.
Invalidating the cache is not a great option.

Maybe a dedicated URL could work.

Re: statamic/v2-hub#1636

If we change the URL, we need to make request based things on the view continue to work.
Like segment_x variables or tags etc that are relying on the URL.

Finish "Getting Started" widget

v-popover tooltips are interfering with dropdowns

Hook up loggers

Hook up Mail

Extension file generation commands default to the App directory

• Generator php please make:tags Something should output to app/Tags/Something.php with an App\Tags namespace.
• We could add an argument to specify an addon location instead, to mimic v2 behavior.

Asset Container URLs

Now that we're using filesystems.php we will rely on Laravel's url methods.

Probably need my PR to be pulled down before it can work.

Import Site Helpers from v2

Related to #11 we should automate moving site/helpers/Tags.php to app/Tags/Site.php and so on.

Use new Translation methods for the Control Panel

Instead of keys, we should use English strings.

{{ translate('cp.hello') }}

# en/cp.php
return [
  'hello' => 'Hello',
];

# fr/cp.php
return [
  'hello' => 'Bonjour',
];

becomes

{{ __('Hello') }}

// fr.json
{
  "Hello": "Bonjour"
}

Wire up table column customizer so it persists

A little something like this:

Replace the pass-through resource server with something better

In v2, we serve CP assets by using a /_resources/... route that goes through a mini server.

For v3 we want to just make the assets exist in the webroot so we don't have to do any PHP handling.

Something like php artisan vendor:publish that brings across the CP assets into public/resources/cp.

We also need to figure out how to load addon assets. (eg. /_resources/addons/addonname/etc.js)

Smaller IDs

A random, purely cosmetic idea.

Instead of UUIDs all over the place, it would be nicer if we could use something shorter.

eg.

id: 0a70b7a0-9f1c-11e8-b568-0800200c9a66 # blah

id: 1  # noice.

id: 5bAyD0LO # also nice

Doesn't have to be for 3.0 at all.

We could swap out any instances of Helper::makeUuid() where it's being used to generate IDs, for something like EntryRepository::createId(). The default implementation (the Stache) could use UUIDs to act just how it was. A DB backed implementation might get the next primary key.

An improved Stache version could be to just store an integer somewhere and increment every time it's used. Then use that integer, or wrap it with Hashids. Of course, check that a certain ID has already been used when generating a new one, just in case.

User Groups

In v2, users are tracked within the user groups yaml.

With #9 it would be nice to move user groups into a config file. However, we don't want to track the users in there.

The idea is to flip it, and put the groups within the user's yaml.

v2:

# groups.yaml
admin:
  title: Admin
  roles:
    - admin
  users:
    - john

v3:

# config/auth.php
return [
  'groups' => [
    'admin' => [
      'title' => 'Admin',
      'roles' => ['admin'],
    ]
];

# users/john.yaml
name: John
groups:
  - admin

ensure_unique_ids check can be removed

This setting was relevant when we would just throw an exception.
However, now we simply track it and show the duplicates in the Control Panel.

There's no reason to disable this now. It only existed to prevent crashing the site with the exception.

Implement Asset Container creation command

Now that all the credentials etc live inside config/filesystems.php, maybe we can just output the php to screen and say "copy paste this to x".

Something like

$ php please make:asset-container

... enter credentails, test an api call, etc

A container has been created at `content/assets/yourcontainer.yaml`

Copy this into the `disks` array in `config/filesystems.php`

'yourcontainer' => [
  'driver' => 's3',
  'key' => '123',
  'etc' => '...',
]

Move publish status into a variable instead of an underscore in the filename

Avoid annoying git diff/history issues.

First

It was too heavy of a decision to decide on what the first issue should be.

Instead, here is Nick Offerman.

Ability to install addons in the Control Panel via composer

Refactor the View class to promote extensibility

Would like addons to be able to hook in and do their thing, such as modifying the template and layout being loaded.

Sort out the colons in array_get

We currently override array_get() to support colons as the separators.

There's no elegant way to do this. Making our helpers file load before Laravel's is hacky, and an actual PR/change to Arr::get() might have side effects.

We should just deal with not having it support colons, and adjust whatever bits are relying on colons.

I know this will mainly be a change in the parser. We can probably even just replace array_get in there with $this->arrayGet() that does the colon replacement.

User changes cause duplicate IDs

When editing a user, a duplicate ID error is created. Was fine in v2.

Composer equivalent to the updater migrations from v2

The v2 updater let us define migrations when updating from/to specific versions.

Maybe we can have a pre-update command that stores the version on disk somewhere and uses that in the post-update to perform necessary migrations.

YAML converts arrays to short syntax too early

eg.

fields:
  name: { display: Name, validate: 'required|min:2' }

This should be

fields:
  name:
    display: Name
    validate: 'required|min:2'

The short syntax shouldn't happen until several levels in. Maybe never?

Get Search working

Extremely vague issue. Get it working v2 style. Maybe improve it in general.

Evaluate adjusting paths

The paths for things in v2 were relative to their Flysystem disk.

eg.

• Entries were collections/blog/post.md instead of site/content/collections/blog/post.md
• Users were bob.yaml instead of site/users/bob.yaml.

It may (or may not?) be a good idea to make all paths relative to the root now since the disk concept really only exists now for backwards compatibility.