How many people here using a WordPress site to display their pictures (or include their pictures in stories) after editing them in WordPress ? (I know @beachbum and I do, who else ?) In an era where social media increasingly suck (human body censorship + privacy issues + copyright forfeiting), I think personal blogs are becoming cool again, but still too complicated for some people.
I have felt the need for a direct WP exporter in darktable for several years, but I now have the skills to do it, so…
I was thinking about the following features:
export pictures to media library,
create a new post (possibly custom types) with exported pictures in a gallery, and set the title, category and tags directly from dt interface,
fill the usual tags of the pictures (title, alt, legend) with darktable masks ($title, $author, $copyright, etc.)
possibly keep track of the picture or post URL on the website in the darktable database.
fwiw we moved the dt website away from wordpress because it is bloatware and has security issues. if people host their own websites, why can’t they use an honest static generator like the website export dt already has, or maybe something with markdown/pelican support if it needs to be more full featured?
The problem I see with all this web service/site exports is, that they change from time to time the API and you need to react to that change with a new release to fix it. darktable had this problem in the last years with facebook and google.
I have no clue about the WordPress API but it should be not to hard to hack a small Lua scrip that exports the images, creates with curl the post and then adds a tag to the photos.
I know. But WP is still one of the easiest and most versatile way to host any kind of website, with a large ecosystem of plugins (even security ones) to extend it. Some people may need ecommerce, memberships, or simply collaborative writing features and scheduled posts, no static generator will ever allow them to do that.
BTW I have never been able to use the static generator for dt.org: it needs Python 2.7 and I just stopped trying after 3h of libs fixing. Also the git versioning + Python generator casts a lot of possible writers out for lack of technical skills.
Static generators are suitable for a very narrow audience of power users.
WordPress is opensource, so at least we can have more information, or even have a dt plugin on server side.
Given that python 2 is about to die (finally!) that means we need to check python upstream if there is a python3 port … or port the sites to hugo. which powers digikam, rawtherapee. and IIRC Pat wants to move pixls.us too.
you also add lots of layers (php, a database) for displaying simple content. the richness of the content comes from javascript and other things that work just as fine with static generators.
And trust me I went through a lot of those classic CMS in the past. saw them die. being hacked constantly and the code is only nice if you dont look at it (for your own mental health dont look at it, I just did that mistake with nextcloud and pixelfed).
so that said … netlify and forestry allow non nerds to edit the content. In theory you could achieve something similar with the wordpress static exporter/cache plugin.
How do you manage pictures and posts collections without some sort of database to look up ? And comments/interactions ? How do you send your new posts by email or cross-publish them on social media ? Or manage them when you have 10 years of archives and hundred of them ? Are you going to edit your server files every time you need to redirect an URL that has been changed or trashed ? How do you put up a contact form ? How do you restrict some posts to some audience ? How do you give publishing rights to several users ?
However ill-coded those soft might be, they are full-featured and pretty easy to use. Once installed, there is not much you need to care about anymore.
I mean… Social media have taken most of the market share of blogs in the past 10 years because of the ease of immediate interaction and targeted publication, and your proposal is to make blogs great again by stripping them of all the features that made the success of social media and making them static to ensure they will never have these features ever ? Isn’t that classical opensourcery, as in “tell me what features you need, I will mansplain you how to live without them in the OpenSource galaxy” ?
I’m sure static generators are great to build websites for people who don’t really need websites.
There are 75,000,000 sites running WordPress right now, that’s a third of the web, and the last release has been downloaded more than 9 millions times.
How many of them are interested in a darktable bridge ?
That’s all I’m asking. Whatever CMS gets the love of people who can read code is no concern of mine. If static sites were a true need, Microsoft Frontpage would run a third of the web right now.
The Lua script for the export would be shorter than this thread. Do you have a test WordPress installation and a link to the API? Then lets start hacking a prototype.
I understand the allure of using something like Wordpress for some sites. It’s fast and easy to get started and everything is right there.
The problems with a CMS in my opinion are:
Security.
The attack vector for a CMS like Wordpress is relatively huge:
a. PHP vulnerabilities on the webserver require maintenance and updates to stay safe (assuming there’s not another layer of framework or something that might require even more).
b. SQL vulnerabilities have to be watched as well.
These two services (SQL and PHP) probably make up the vast majority of security issues on the internet right now.
Don’t forget that you’ll need to keep the entire CMS system updated on the server to make sure you’re safe.
Flexibility.
Sure, things seem fine as long as you’re willing to delve into the particular of building out templates and custom code for sites using whatever arcane method of use the system requires. It’s certainly not impossible, just unwieldy and very specific to the CMS.
Speed.
Even with some caching there is a requirement to hit the server-side script and possibly the database before serving up data. Might seem trivial until you get an occasional spike in traffic and realize you can’t really serve more than a few dozen simultaneous requests.
Use case.
If the content is truly static content, then a CMS with database and scripting language to parse on the server is just overkill. And honestly, most of the internet can be served as simple static pages without requiring server-side scripting.
What is nice about CMS is the WYSIWYG interface for most people and the ability to fiddle with shit endlessly (similar problem I have with MS Word or a WYSIWYG “document” editor).
Using a static site generator…
Security.
It’s just serving static content from the filesystem from nginx/apache. The only service you need to make sure is secure is the webserver. If you don’t update your build system in a few months it doesn’t matter because the content is still unchanged and only providing static files from the webserver to serve.
Flexibility.
This is a little more complex to setup initially, but if done correctly allows users to focus on content later on and not worry about fiddling with how something might look (WP does this too to some extent, but with a prettier interface).
Speed.
Just like security, I’m just serving static content from the web path. This will always be faster than any CMS by order of magnitude in some cases. We can handle hundreds (thousands?) of simultaneous requests without even breaking a sweat on the webserver.
That being said, I can completely understand why some folks would rather use a simple exporter directly to something like WP, but I do believe in the end the same or better can be accomplished with an SSG.
Some of them are quite nice these days (Hugo has done a great job of data types and management, including all of the essential “social” stuff that people like to add - check the opengraph/schema stuff that’s baked right in by default).
In fact, you could theoretically just dump photos into a directory structure and drop a .json or text file next to them that has metadata tied to them and let the SSG handle rendering the page pretty quickly.
This isn’t a theory if you’re using Hugo. It can parse json and CSV, so if you can export those formats for your album, you can use hugo to loop over it and generate the page.
Well, I wanted to avoid Wordpress at some point of time because of its size, but other CMS are similar or even bigger. On top, WP has a plugin for everything you need and you don’t need to code your own. And for me most important, there are lots of booster that are specially designed for WP (such as EasyEngine, Centminmod etc.) that work only somehow with other CMS.
