In a bit of irony, I've just spent the last weekend digging around and researching CMS'es... I started with database drive systems, and then, thanks to LostInBronx and Klaatu (for running their gaming site on Grav) looking at flat file CMS's.
The main issue with going the flat file approach is building index pages. Every time a new post (show) is added, all of the index pages would potentially need to be re-built. Personally, I am trying to decide what the best approach is for my situation where I have ~500 articles that will be growing after I move to a new system... A purely flat-file CMS might not be the best approach...potentially something that is more of a hybrid system like Bolt CMS might be better -- and it might fit HPR's needs too (it does use a database, but it only need SQLite, and not Maria or Postgres). I'd be interested in hearing any input others have on this topic. George On Mon, Apr 15, 2019, at 1:43 PM, Ken Fallon wrote: > > On 2019-04-03 20:36, Ken Fallon wrote: > > Hi All, > > > > Do any of you have a recommendation for a Static Site Generators that > > just publishes html files. > > > > For example takes a page, adds a header and footer from somewhere and > > publishes the combined page. > > > > > > Hi All, > > Thanks for the suggestions, which I am working through. > > The question was in relation to the Hacker Public Radio site, which is > essentially a LAMP based site that is entirely database driven. > > For the vast majority of the site this is unnecessary as the pages are > very static and change infrequently if ever. Those could be written to a > static html file without a problem. > > The general goal is that everything could be rsynced from a server to > your local machine and you would get access to a daily snapshot of the > entire website. This would allow us to have multiple mirrors of hpr > around the place in the event of another DDOS. > > So the php page > http://hackerpublicradio.org/eps.php?id=0013 > > would be written out to a directory accessible via a index.html page under > http://localhost/episodes/hpr13/ > > This fixes the problem of the episode 9999 bug, and removes the need for > a database query for the page. > > Unfortunately if ever the header and footer change we need to change > each and every exported page. HTML5 had a way to include pages together > fixing the problem but for some reason support for that has been dropped. > > So that is why I was thinking of a flat file CMS. The down side of that > is that if there is a change of header, then every single "rendered" > html page would need to be downloaded again because the change is > incorporated in every single page. > > However after thinking about it for a while, the people who are helping > out by doing this must have the technical expertise to rsync the site > locally. So it's safe to assume that they also can follow an instruction > page on how to set up a local lamp server. > > Then we could actually distribute a more or less static html website, > but use php to include the header and footer. That would not exclude the > need for a flat file cms, but the integration would be more focused on > the dynamic content. > > So I intend to setup a git repo with a index.html page that uses php to > include a header and footer. Trying to make the local site at least > usable if php or a webserver is not available. > > I'm not sure if this is even something that would be of interest to > people, but if it is, then I will put up links when I have something ready. > > -- > Regards, > > Ken Fallon > http://kenfallon.com > http://hackerpublicradio.org/correspondents.php?hostid=30 > > > _______________________________________________ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > > > *Attachments:* > * signature.asc Faster moments spent Spread tales of change Within the sound
_______________________________________________ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
