serve themes from the status directory

[WardCunningham]

This commit routes requests for theme content to an optional subdirectory, theme, in the sites status subdirectory. This commit, coordinated with a companion commit in wiki-client, will allow a site administrator to configure custom css on a site by site basis. Future plugins might expose this capability to the site owners too.

See https://github.com/fedwiki/wiki-client/pull/133

[WardCunningham]

A good test case for these commits is to change the active page halo to red.

Add this css to a site of interest by editing the site's status/theme/style.css file as follows:

  .page.active {
    box-shadow: 2px 1px 24px rgba(255, 0, 0, 0.4);
    z-index: 10;
  }

[paul90]

Add error handling on res.sendFile, so rather than Error: ENOENT, stat '..../.wiki/status/theme/style.css' at Error (native) errors are correctly handled and appear in the log just like any other failed get GET /theme/style.css 404 - - 4.839 ms

[paul90]

Would a theme be better served from a theme directory in the site's directory, rather than a directory inside the sites status directory?

[WardCunningham]

Logging makes sense, I guess. I wouldn't consider the absence of a theme to be an error condition. I guess common practice is to log the absence of favicon.ico files when the browser is just probing, as we are probing here.

My first thought was that theme.css should go next to favicon.png, another theming element. But then I realized that the css might want additional files, background images in particular, so I added the directory. But it still feels like it belongs in status. This is handy when administering a site from the command line: two directories, pages and status, one for standardized content, the other a catch all.

This does raise a question, will our database versions of page/status stores handle this extension?

[almereyda]

Thinking about the status and pages stores as different in their quality arrives to me from how BLOBs are handled by the respective storage engines. Then the directory structure is just another data model to be represented on some abstract level. A graph could be a thing here. I'm just thinking from IPFS' perspective. To them directories don't appear different than any linked list.

I could even imagine seperating these stores from an operational perspective. Ideally I want to equip my immutable containers with a simple payload of stateful customizations and a set of environment variables. (Why again did someone lately argue we shouldn't call them like this?)

Service ciscovery would then have a look for the more often changing data, escalating in gradual scales. Where the sitemap and link networks live closer to the sockets.

---

Having said this; I thought this is merged already? How can I put this on staging somewhere? Why doesn't @federated-wiki have resources available already? And what's the Federated Commons Cloud by the way, @gandhiano?

And I just finally wanted to write a small customization for a GNOME 3 Adwaita dark theme compatible set of CSS rules, as promised to @opn.

[WardCunningham]

@almereyda -- You can create public scoped version of wiki-node in npm. This then can be conveniently installed by yourself and others. @nrn brought this possibility to my attention while reviewing advanced documentation about custom plugin configurations. The same techniques work for any server, client or plugin customization.

http://plugins.fed.wiki.org/view/welcome-visitors/view/about-plugins/view/maintaining-a-custom-wiki

I will add the public scoped version details to the above page once I work through them myself. The steps as I understand them would be:

• clone wiki-node
• edit its package.json to load the experimental branch ward/theme
• edit its package.json to be a public scoped version of wiki-node
• publish this to npm

Having done all of this, anyone can run this version of federated wiki by installing it from npm.

Here are some npm docs that explain these capabilities.

https://docs.npmjs.com/getting-started/scoped-packages https://docs.npmjs.com/files/package.json#git-urls-as-dependencies

I like this approach because it grants to you the same privilege anyone else has to distribute federated wiki configurations. This also only uses services upon which we already depend: npm and github. Further, this dependency is only a convenience. We can move our work elsewhere should they fail to provide the service we expect.

[paul90]

Just changed the error handling, so an empty string is sent as the css if a theme is not defined. This prevents the client seeing an error. But, still raise error for anything else in the theme directory.

I think this and the associated client change can be merged - so they don't get forgotten...

[WardCunningham]

I think I underestimated the complexity of scoped versions in my response to Jon above. Does any of the discussion we've been having about plugin versions bear on this logic? I ask because I'm sitting in a conference session and not immediately able to answer the question myself.

[paul90]

This pull request is not connected with scoped versions.

I am still not too sure about adding support for scoped versions beyond the wiki package, to make it easier for custom collections of plug-ins. But, beyond that I am still not sure where the rabbit-hole is leading, it seems to be adding lots of complexity, and not currently too sure how frequently it would be needed. A simple approach might be to use a git branch, and modified .gitignore, and install from github.

[WardCunningham]

Yes, scoped names do seem to create as many problems as they solve.

I'm still happy to merge this and see a little bit of graphic expression. Thanks for handling the error condition.

[opn]

Could we possibly have a similar global custom theme location to override default CSS for all sites in a farm?

[paul90]

An interesting idea.

[opn]

Ideally this would be linked to how npm install works when pulling in custom package.json? That is you could somehow add the cuss to the forked repo, and from then on your updates will pull in your custom cuss from GitHub or elsewhere?

[WardCunningham]

I was hoping that git's renowned merge capability would take care of this need for us. That is, server-wide css changes would be made to style.css and merged with the upstream when convenient. I'm not finding this super convenient but it might be that I am just not as good at git as I thought I was.

This leads us to the question, why is programming hard?

My own pet theory is that all software systems accumulate features until nobody can understand them anymore. Our style.css might be drifting in that direction. The only way to fight this is to refactor toward smaller and more leveraged abstractions. Let's be sure we are always moving in that direction.

Aside: As I reread this thread I see that my comment here contradicts those I made earlier. This just shows that we are walking a tight-rope and can fall off either side.

[paul90]

While it would be possible to do this using git, it would require creating a scoped version of wiki-client. This is where the complexity level starts ramping up.

I think such wiki farm wide css, and associated files, would more rightly belong with the farm's data in ~/.wiki, say in ~/.wiki/theme. One idea would be for the server to detect the presence of a farm wide style and serve that rather than the style from wiki-client.

[opn]

@paul90 I think this is the simplest idea - ~/.wiki/theme/style.css

My question may show a lack of understanding of npm - but given that package.json can specify installing binaries, and as far as I can tell pretty well anything anywhere - why can't we use that to also install the css file in ~/.wiki/theme?

Of course a user can simply do this by hand - but given that we are encouraging them to use the fork + npm install -g git://github.com/<you>/wiki.git technique for custom plugin configurations - why not use this for keeping / installing the css file as well. Then updating and sharing of css is made easy as well?

[WardCunningham]

@paul90 Perhaps the server could concatenate the various css files in such a way that cascading works as one would expect: site overrides server overrides distribution. This would be a feature of the server. I'm sorry I got the client static html involved.