I’m planning a restaurant website on DreamHost using Elements for the design and public presentation. Before starting development, I’d like to confirm the simplest supported way to manage CMS content entirely on the server.
The proposed workflow is:
A separate PHP application maintains menu information and staff-created food/wine features.
That application generates Markdown files with frontmatter, plus feature images.
Elements CMS Collection and Item components display that content.
I continue using Elements on my Mac to change layouts, navigation and styling.
The server-generated content would be authoritative. I don’t need to edit it inside Elements or synchronize it back into the project.
Could you clarify the current behavior and recommended configuration?
Can I connect a Collection to a CMS folder in the project, but keep its actual Markdown records exclusively on the server? Would both normal publishing and Re-Publish All Files leave those server-only records untouched?
Is overwriting limited to files with matching paths and filenames in the project, or are there other CMS publishing behaviors to account for?
Is there a supported way to exclude CMS content from uploading while continuing to publish the page layouts and CMS components?
Where should externally managed feature images live so Elements publishing leaves them untouched?
Does this arrangement require CMS Pro, or can the standard CMS display externally generated Markdown without the online editor?
My goal is to use the built-in CMS components with as little custom integration code as possible.
The acceptance test would be simple: add and update Markdown and images directly on the server, then change the design in Elements and republish all files. The latest content should remain intact and display correctly.
If this workflow is supported, an example folder structure and the relevant Elements settings would be very helpful. Please also indicate any version requirements.
What you’re planning can be done with Elements without any problems.
You’re completely free when it comes to the folder structure for your Markdown files and images. You can name the folders however you like and store them wherever it makes the most sense for your setup. The CMS doesn’t impose any specific folder structure.
For example, you can continue storing your images under /resources/, or create a separate directory specifically for them. Personally, for simplicity, I keep all my images under /resources/.
For my Markdown files, I’ve created a cms-data directory, with separate subfolders for the different types of content. But again, you can name these directories however you like and place them wherever you want.
CMS content can also be excluded from publishing in the same way that you can exclude “normal” Elements pages from being published.
Thank you—excluding CMS content from publishing sounds like exactly what we need.
In Elements 2.4.4, where do we set that exclusion? Can we exclude an entire CMS content folder while still allowing a Collection on a published page to read its server-side Markdown?
Does that exclusion also remain effective during “Republish All,” leaving both externally updated Markdown files and server-only Markdown/images untouched?
However, I think your general approach is the wrong one.
The main question you need to answer is: Do you want to store and manage your Markdown files inside the Elements app or not?
I would advise against using a hybrid approach, unless you have specific content that should only ever be modified through the app.
If you want to manage your Markdown files exclusively on the server or via a file manager, then there should ideally be no Markdown files stored inside the Elements project. At most, I would keep a single placeholder or test file in Elements so that you have some sample content available in the preview when making layout changes.
My recommendation would be to keep a local mirror of your Markdown files on your Mac. Any changes or additions to the Markdown files are made there, and once you’re finished, you simply upload the files to the server.
This keeps things clearly separated and avoids having two different sources that could potentially overwrite each other.
Thank you—that separation is exactly what we intend.
Our production system will manage the content and generate Markdown/images directly on the server. Elements will manage the layouts and display that content through Collections. We don’t intend to maintain editable production Markdown in both places.
The matching local/server file was only part of a disposable test to establish publishing behavior. In production, we would keep no live Markdown in Elements, perhaps just an excluded preview sample.
With that arrangement, can we point a Collection at the server content folder and safely use Republish All without affecting its Markdown or images?
