Perch: a really little CMS | Hacker News Reader

Perch: a really little CMS

grabaperch.com

87 pointsTomte88 comments

There's a ton of these little php CMSs but it feels like inheritating the entire attack surface of LAMP or even just an apache + php stack is insane these days.

Use a static site generator. Maybe have a nice UI around it. Publish the whole thing to S3 or whatever CDN fronted storage solution you like. Almost no attack surface, mindlessly easy, very cheap.

> Maybe have a nice UI around it.

I only know about Lektor and MovableType. Arte there more SSGs with some kind of web interface to write and edit posts?

Forestry.io supports an entire mess of site generators including Hugo and Jekyll. You can also leverage Github or Gitlab's ui directly to edit or create files.

Forestry.io is a nice wrapper around a bunch of SSGs, backed by git. It's a paid subscription, but with a pretty generous free tier. I'm using it so my less-technical co-founders can edit our Jekyll-based support site.

Jekyll has jekyll-admin: https://github.com/jekyll/jekyll-admin

publii has a very well polished GUI https://getpublii.com/

Use Stackbit to create your combo of SSG, Theme and CMS. https://www.stackbit.com/

Stackbit really is a great product! I was able to throw up a marketing site for my family's rental property in a few hours for some non-technical people to manage.

You can also use something like NextJS's static pages, where you can still use React for client-side interactivity that doesn't require dynamic server communication.

> Use a static site generator.

Regardless of how you serve the end-user site (generated ahead-of-time or at request time), there's enormous value in backing it with a database and providing non-technical maintainers a friendly UI over that database for managing their own content. If you want something more minimal than the OP, you might go look up something called "Headless CMS".

Forestry.io is a headless CMS that is backed by Git. It is made for Static Site generators and the content is still kept in your repository.

This looks really cool though it seems awfully close to editing Markdown and pushing to Git directly. I suppose the value it adds is abstracting away Git operations for non-technical content editors?

Yup, pretty much. I’ve not worked extensively with Forestry, but I have with Netlify CMS, which is an alternative with a very similar premise. My experience was that it’s very difficult to build a robust CMS on top of markdown. If basic content editing is what you need, great! If, however, you need to accommodate a variety of conditions, things get dicey fast. The issue is that it’s exceedingly difficult to program or direct a CMS how to reason about even the most rudimentary primitive values or types in something as simple as markdown. After all, things are either there or they’re not. This can quickly causes your view layer to swell into an unmanageable mess.

Overall, I’d use it for personal projects if I were feeling fancy (I rarely do) or client projects with very simple requirements.

Forestry does a lot more than just abstract away the Git operations. It has a very advanced front matter template system that makes it possible to build very complex content models while providing a nice and simple UI for managing content, menus and media. It’s really quite impressive.

We’ve built a few sites on Forestry + Hugo and are very happy with the combination. https://www.jetflite.fi is a good example of a site having a rather complex content model.

Is it just me, or does every page on forestry.io take 4400+ milliseconds to load? I can't even use the website because it's so bad.

It isn't just you, I tried and see my self staring at their blank pages for a few seconds and then everything appears at once.

> providing non-technical maintainers a friendly UI over that database for managing their own content

how is git based Content management adequate for non-technical (read "WTF is GIT?") users ? That's why i still deliver throughout WordPress

"backed by git" doesn't mean the user has to interact with git at all. The user makes a change in the interface, the CMS creates a commit and pushes to the repo.

I'd love to see a CMS that runs on your local PC to drive a well-known static generator (Hugo, jekyll etc). This seems like the best of both worlds; no attack surface and easy to use.

https://getpublii.com/

There are others as well.

TinaCMS supports this exact thing with Gatsby and Next.js

There's also been some prototypes of TinaCMS being used to edit Hugo sites.

https://tinacms.org

Just configure your headless CMS to make changes to your local git repo. NetlifyCMS can do this, I am sure the other ones can do too.

I've had good experience with Lektor for simple web sites.

https://getlektor.com/

There's nothing saying you couldn't provide a friendly UI on top of a static site generator. The first big hit CMS for publishing blogs, Movable Type (https://en.wikipedia.org/wiki/Movable_Type), worked exactly that way -- it used MySQL as its content store and provided a nice WYSIWYG interface for working with content, but when you hit "Publish" it ground out your site as a set of static HTML files.

The parent comment seemed to be suggesting that people use a static site generator "instead of a CMS". Part of what I was trying to do with my comment is point out the orthogonality of the two. A static site generator is just a glorified cache over a normal web server.

Kinda agree. I use Airtable as the CMS for my personal website, and it's actually pretty quick to whip up pages with Gatsby (or whatever floats your boat in terms of SSG), then throw it onto some hosting and tada!

I even made some webhooks so I can trigger rebuilds from within Airtable, so when I change stuff I don't need to worry about going to the host and manually clicking rebuild.

I was just thinking that static site generators would deserve their own awesome list, and there we go. Someone already made one.

https://github.com/myles/awesome-static-generators

https://staticsitegenerators.net/ includes a comprehensive list and has been around for a while.

Even better, and sortable. Thanks!

Those "awesome" lists don't make sense to me because they just end up being a crowdsourced list of every piece of software in <category> with no moderation for quality.

Yeah, I’d like to see at least some kind of ranking and an idea how big/active the ecosystem around a project is.

How do you solve the "search engine" problem with a static web site ? I never found a solution for that issue. I want to search in my blog, full text with no external service.

If the site is small enough, you could use something like this: https://github.com/weixsong/elasticlunr.js

Basically compile the text content of all your files into a JSON file, and search over that in JS. If the site is not small enough for this approach, go with an external search provider or don't make it a static site.

“It’s all about the comments”. All these static site generators are fine but they can’t deal with comments. Then you have to add a commenting system from a 3rd party, at which point you may well wish you’d just gone with a PHP/DB solution from the beginning

Well I just launched fastcomments.com which you could use :p

https://fastcomments.com/

I appreciate the pricing~

Thanks. HN helped with it! :)

It isn’t clear to me what the individual tier allows, except for the pageview restriction. There is no FAQ or Support link on the homepage. Is it one domain where all sub domains can have comments enabled? Or is it one subdomain in a domain? Or is it all (disparate) domains owned by an individual?

Yeah right now you have to have an account, then you have direct access to customer support via the UI.

A FAQ page I should put together, that's correct.

Your questions:

1. The tiers differ in pageview restrictions and developer support access. The highest tier provides migration support for the platforms that don't have automated migrations today (you can import from Disqus, Commento, and a couple others).

2. Right now domains are unlimited and validated at TLD. When you sign up just enter the sites you want to use like.com, this.org. For example, I dog-feed it on my blog at blog.winricklabs.com, but I only have winricklabs.com on my account.

Are there any plans to add a free tier without support or migration for say, less than 100k views a month? The pricing seems pretty neat if you're closer to the limit of the pricing ie one million page views but if you're at the other end of the spectrum then it's significantly better to go with a free solution

Don't want to support a bunch of free customers at the moment. Maybe later.

I think it's a good call.

For the sake of clarity, if I have 2 domains, is it $4.99 per domain, or can both domains come under a single $4.99 charge?

Both as a single charge.

Do you have a react component for this ?

You mean as a wrapper? I'm not familiar with react as an Angular guy, but do you need one - could you plop the HTML into the page? All the client side script does is insert an iframe and control its size.

I'll look into making a React component.

react does not play well with non-react javascript

> react does not play well with non-react javascript

I'm work on a somewhat older project (circa 2015) that started without react, and have also found that to be the case.

End-all-be-all web frameworks seem to be the rage now, but I'd prefer to see a solid library of micro-frameworks that can be stitched together (like jquery plugins, but better).

Also, the idea of a web server transferring over a huge javascript library and app just to load a single page seems wrong. There has to be a better way, a better amalgamation between server and client.

to be fair, the problem seems to be in the jquery side. It was not built to play well with others.

Also React fundamentally assumes it is the only one modifying the DOM through its virtual dom. If something else changes the DOM (like jquery), then React falls through.

I won't be doing that! Offering a full react version.

I'll just write the client in React then. It's like 30 lines of code that pulls in and resizes the iframe.

What happens if you shut down the service, are there any guarantees on availability? How can I export my data and could I import it somewhere else reasonably easy?

You have full access to your data via the UI (csv exports all db fields).

You can use webhooks for this. As an example: https://staticman.net/docs/

I just ditched comments entirely and don't miss them. Comment volume didn't change, but people email me now instead.

> people email me now instead.

And then you manually add that to the article or just keep it to yourself?

A little of both. This is for a fairly low-volume personal tech blog so of course this wouldn't really scale. When I do add a comment to one of my pages it's not presented in the typical comment thread way but more like an edit that thanks the person and rephrases what they had to say.

check out FactorJS

Got rid of comments altogether as being generally Far Too Much Headache given the cohorts of spammers, bots, trolls, black-hat pen-testers, etc., etc. If anyone reads my website (Hi! to both of you...) and wants to comment, there are contact details right there with various ways to reach out. If it ever got to the point where there was a 'community' (dubious concept, that) developing, well,... just set up a subreddit, IRC or Riot channel or something.

Who did you quote? ("It’s all about the comments" )

I'm curious about what you think about Talkyard-blog-comments https://www.talkyard.io/blog-comments (I'm developing it), in comparison to a PHP+DB approach? (Pros & cons? if you have time)

I used to use Perch regularly for the small sites I was building 8-10 years ago. It fit perfectly into my workflow when I was running a one person shop: 1. Design in Photoshop 2. Build the static HTML and CSS 3. Integrate the CMS and deploy. Perch always made the final step so easy and clients liked it, so I was very grateful for it.

This looks like it’s based around the “page” paradigm, which is fine for some sites, but for many types of sites I’ve found that you often want to manage entities with a set of custom fields instead of full pages, then compose the pages from combinations of these entities.

I’ve been pretty pleased with Cockpit CMS (getcockpit.com) for these kinds of sites. It’s a headless CMS similar to something like Prismic or Contentful, but it’s self-hosted and open source. It uses PHP and SQLite (which means it’s easy to host wherever) and the code is fairly easy to understand if you do want to make changes.

The way I’ve been working with it is using Cockpit to manage the content, which is then consumed by a React site via Cockpit’s API. In order to decouple the CMS and the actual site (and to provide security, versioning and fast page loads), I use react-static (also highly recommended!) to create a static HTML/JS site - so the workflow is: edit content in Cockpit, then trigger a build (I use Netlify for this) which generates a static version of the site which you can then preview and publish easily - it’s just HTML and JS files.

You could use e.g. Drupal or Wordpress to do this with the right plugins, but I’ve found the level of complexity there (both from a developer point of view, and for end users especially in the case of Drupal) too high for simple freelance projects. Cockpit strikes a good balance of flexible yet easy to understand and customise for me - I did also investigate some options such as Netlify CMS, but at the time it didn't seem flexible enough to meet my requirements, this may have changed!

hi there, thanks for sharing. How is the workflow for a preview feature ? Meaning, i'm editing content, i kinda want to see what it will look like IF published. Should i wait for an entire build of (assume 30 to 100) pages just to see this new/updated one ?

Ah, yes unfortunately you do need to wait for a build in the way it’s currently set up. The largest site I’ve done is probably in the 50-100 page region and that does take 2-3 mins to preview. One option might be to run react-static in dev server mode on a server to generate the preview, this will generate the site on the fly rather than in advance (as it’s intended for development use with hot reloading etc) - I’m thinking of trying this on my current project.

contentfull and gatsby are kinda tacking this exact preview issue. But telling a non tech editor to wait for several minute for a preview is a big NONO from my side.

Sadly contentful is not free in a nice free tier

(0): https://www.contentful.com/blog/2019/04/24/content-preview-f...

Yeah, it does depend on your requirements of course, the sites I’ve used it for are freelance sites for small companies for whom waiting a minute or two isn’t a big problem. Should also note that I don’t think Cockpit has versioning or draft states so probably not suitable for a “big” site with lots of editors etc.

Like I say, the dev server route may be a way to make this more dynamic. Another possibility is that it seems like react-static can now do incremental builds for only a subset of routes, so you could just republish a given route I’d it’s easy to map from CMS entity to affected route(s).

One other thing to keep in mind is that for some categories of site, moving away from the “managing pages” CMS model to the “managing content models” often makes the site much easier to manage (e.g. you can’t break the layout by editing the wrong thing in a wysiwyg editor) so there may be less need for frequent previewing.

But I agree, not a solved problem yet. Running the preview on the dev server is the best I can think of for now. You can imagine some kind of site-aware CMS that understood how entities mapped to components and could show inline previews in a React Storybook kind of style, that could be neat!

For the record, I did go with the route of running react-static in dev mode on the server for preview (using Phusion Passenger to run it, as this was set up on the server, which required an app.js file to start the server: https://gist.github.com/tomduncalf/00070fecb68a6cf35c0102c75...). Seems to work really well.

I've got another simple server at "/restart" running which touches "tmp/restart.txt" when hit which forces Phusion Passenger to restart the dev server, which forces it load the content again. Takes like 10-15 seconds to be ready to preview, client is very happy compared to the old setup which required a few mins of building to preview!

And yes, Contentful pricing is not suitable for small businesses IMO. Ramps up too quickly. It’s a pretty good CMS but for my freelance needs, Cockpit is fine.

> you often want to manage entities with a set of custom fields

Perch Runway (the big boy version of Perch CMS) can handle exactly that, although I've never personally needed it, I usually just stick with regular Perch because I'm more familiar with it and you can kind of shoe-horn some collection-like behavior into the page paradigm well enough.

Personally I enjoy Perch, but I'm also lately getting really into WP with ACF.

I used Perch for freelance web development back in ‘10 and it was great - just the features I needed, and simple enough to share with clients. Well worth the price.

The “elephant in the room” I couldn’t find answered on the site: if I’m going to use a PHP CMS, why would I not use WordPress or Drupal? They both have an enormous community of developers, plugins, documentation, and users. At the moment, this feels like yet another PHP CMS that will become abandonware within months.

Perch has been around for a decade. You never know when or if something will become abandonware, but Perch isn’t something new.

I didn’t realise it had been around for so long. Thanks for pointing that out.

Just a shoutout to Rachel Andrew, the co-founder of Perch, member of the CSSWG and imo the Champion of CSS Grid.

https://rachelandrew.co.uk/

Perch was first launched in 2009 and is very different in architecture from WordPress or Drupel.

https://grabaperch.com/news?page=33

It’s little. I think perch has been around for about 10 years or more.

WordPress is a nightmare as soon as you have to go beneath the surface. The community around it definitely has value, but the tradeoff is a bloated monolith that you have to become an expert in if you want to do any customization beyond drop-in plugins.

And maintaining the security of your installation, when using any plugin, is almost a practical impossibility.

Perch is in a class of CMSes that doesn’t need a lot of that community because the developer doesn’t have as many problems to solve (security, unwanted default behavior, programming against strange old code.) It more “gets out of the way.” The result is lowered cost of development for freelancers and agencies.

Craft CMS is another good example of how it’s possible to successfully compete against Wordpress and Drupal by making the development and maintenance experience much better.

As far as i know agencies try to get off Wordpress and Drupal because it is just horrible dev experience. What gets used most are modern CMSes like Craft, Twill, Kirby, Bolt or Processwire. They are much closer to mvc frameworks. If you want to do something highly custom wordpress will just be in way.

Drupal is a great dev experience, in my opinion. WordPress's code is a dumpster fire, but the recent rewrite of Drupal in Composer is a pleasure to use. A bit of a learning curve, but it is powerful and extensible, plus it has a great community.

This statement can not be left on HN without contradiction. It says more about your dev experience than about Drupal.

Drupal is still horrible. They did not learn from the security issues of the past, they still put lots of php files into document_root, just to mention two basic things.

They are doing it wrong in many ways, and there is no hope the "community" will ever learn, because people with competence already moved away long time ago.

Let a developer with some experience with different languages and frameworks (Java, Ruby, Python, Elixir) - not some single-eyed PHP-only beginner - work for one day with Drupal and then ask her what she thinks about it.

Personal experience, but I developed a few WordPress sites a few years ago and it was an absolutely horrendous experience. The codebase was awful, fixing things was finicky, and design consisted mostly of trying to get rid of automatically generated HTML or overriding poorly scoped (or just bad) CSS. Also, it was more configuration and patching than development. (But took just as long anyway.) Wasn't my cup of tea.

Development has always been much faster in Kirby for me, even when I need to write features from scratch that WordPress has a plugin for. I've personally never missed WordPress's larger community.

Seems great, but gating the demo behind an email signup seems like it would bounce a lot of potential customers. It certainly killed my interest in looking at the demo.

I love it. Use it for client work to this day.

considering how long it took to load the site its something I would never use

It's cool, but I believe this has been posted a few times?

https://imgur.com/a/xHNzuvA

HN doesn't operate on a one-submission-per-topic-forever policy. There are different people online every day who might not have seen the submissions from 2009 or half a year ago, each with a whopping 2 points.

If people think it's an interesting submission, they'll upvote it.

Reply on news.ycombinator.com