I've been looking into things like Docker images, but it looks like it's more expensive to deploy with things like Docker and Kubernetes than it is to use a VPS or shared hosting. And with that in mind, even though it's no longer the late 2000s, shared hosting is a very compelling choice because with the right provider it can be cheap and robust, plus somebody else is handling OS security.
I'm not giving up on Docker just yet, but the learning curve is high.
And even though my current shared host is expensive (it's up to $16 a month), I can do an unlimited number of individual sites using either separate domains or subdomains. But if I "limit" myself to, say, five sites, NearlyFreeSpeech.net is a pretty good deal. I did a test this week with Unison (my file synchronization solution of choice), and NFSN does provide that, and I got it to work. On Hostgator, I had to find a package for CentOS 6 and install my own on the server side.
@passthejoe There is a max width. It's currently 1900px. There's a wrapper div around the whole thing. You can set the max-width to anything you like by just changing one CSS rule. One of the things I was going for is to make it so that every single rule, without exception, does what you'd think it does. The rulesets don't step on each other's toes. Space is controlled pretty deliberately. So for example vertical spacing is handled through bottom margins and top margins are typically zeroed, with the exception of headings. There shouldn't be any dangling extra space vertically or horizontally and the beginning and ends of things.
@passthejoe Yep, I have it centered. If you're not seeing that it's probably related to one of the broken or 1/2 broken media queries. Whatever it is, it will get fixed. This is what I'm seeing (no changes).
Just about everything can be directly changed with a single rule. If you want to change the background behind the wrapper, that's just the the background color on the body element
body {
background-color: #b3c2d0; /* #b3c2d0; – Light bluish grey */
color: #464545; /* #464545; – Med dark gray */
margin: 0;
}
@john_henry_twitter Thanks. Enjoy your vacation! Of course I'd love to have you poke around or help out. It will be at some stage shortly and then we can just keep working on it on and off going forward. That sort of iterative approach will get it where it needs to be I think.
On a 3000px Mac screen maybe users don't have the browser filling the screen, so the wideness of the type doesn't affect them, but on a "regular" laptop screen, which these days is often HD, the browser still pretty much fills the screen, and I'm having trouble following the line from one side to another.
@passthejoe Good feedback, thanks! Maybe instead I'll limit the width of a more interior element. If we're talking about a grid, I think it's probably a good idea not to broadly restrict the width, which would take away the ability to have wider (or more) side-by-side elements. Restricting line length of course makes a lot of sense! So when there's only a single element in a wide container like that it probably should take up all of the available space. Does that seem reasonable?
Look at how narrow the NY Times is making their text window: https://www.nytimes.com/2019/07/08/opinion/berlin-socialism-housing.html
Here's another design that I like:
https://getpocket.com/explore/item/secrets-of-ivy-league-tour-guides
I like the big body type -- it stands out. The thicker serif fonts are nice
Here is the "Get Pocket" home page that leads to more stories in this style: https://getpocket.com/explore/trending?src=top_navbar
I'm not as crazy about the home page as I am the individual items
I’m still unsatisfied with my WordPress install. I think I don’t like how WP handles adding functionality, and the close coupling of design and functionality within the theme. I have an old site which broke under php7 and I finally had to update the theme major version, and I really dislike that every design agency puts in a custom admin area for their theme.
I think I’d like to see a three part division of responsibility: a “style”, a “genre”, and “plugins”. Style would simply be the appearance, fonts, colors, etc. Genre would be most of what makes up a theme, and the “type” of site whether it be a blog, pages, or something more custom. Plugins would simply add functionality. Ideally they would all be tested and fully interoperable.
This would address some of my frustrations trying to use Hugo as well, everything is either just the base framework (e.g. templates, routing) or highly theme-specific.
This would address some of my frustrations trying to use Hugo as well, everything is either just the base framework (e.g. templates, routing) or highly theme-specific.
This is a lot like the way Ode works. A theme is a folder. That folder contains plain old html, css, javascript along with images and whatever else you want to include in your theme (icons, other design assets, etc). You can have as many of those themes as you like. One of the default and any of the others can be explicitly called as part of the URL. If I had a theme called "coffee" that was not the default then I could render a page using the coffee theme with an address like ode.io/some-category/post-name.coffee.
"Functionality" is not munged together with themes.
Extensions, called addins, are just a standalone folders containing a perl script. They are explicitly ordered by the site maintainers (literally you tack a number on to the addin folders name. So the Indexette addin running at ode.io is installed as 04Indexette. Ode recognizes a number of a number of addin routines:
01. inventory_ping_response,
02. replace_discover_posts,
03. replace_find_req_theme,
04. replace_interpolate,
05. replace_posts_sort,
06. manipulate_request,
08. pre_filter_posts,
09. filter_posts,
10. access_head_theme_early,
11. access_date_theme_early,
12. mod_post_file_before_read,
13. access_title_tags_and_body_early,
14. access_posts_theme_early,
15. access_foot_theme_early,
16. access_page_late,
Any addin can implement any or all of these routines. The only one required is inventory_ping_response. Ode runs through the addins directory and for each addin it finds it calls the inventory_ping_response routine to ask the addin if it should be run. If yes, Ode remembers which of the other routines are implemented. As Ode runs it gets to the point where all of the manipulate_request routines for example should be run. It then calls the manipulate_request routine for each addin that includes one in order. Each subsequent addin is unaware that earlier addins have run. There is no intermixing of addins.
It is true that there can be conflicts. For example replace_posts_sort changes the way that Ode sorts all of the posts for the site. If you had two addins installed both implementing a replace_posts_sort routine, the last one would win. The first one would change the sort routine, and the next would change it again, and then the posts would be sorted.
That's about it.
Content is stored in plain text files organized into folder hierarchies, just like a static site. The only difference is that the post files are just content, not all of the HTML that forms the framework of the page (duplicated for every file as you'd have with a static site).
Themes are separate from content. The posts are plugged into the theme.
Addins are completely separate. There are no references to addins in themes or vice versa.
It could be that an addin requires a specific theme be installed (along with possibly many others). For example the editedit addin allows posts to be edited in a browser. It comes with it's own theme that includes the form fields necessary to input the changes. So the theme is the interface for the addin. But then that special theme is just part of the addin.
As for Wordpress. I don't like it. :)
"Functionality" is not munged together with themes.
Extensions, called addins, are just a standalone folders containing a perl script. They are explicitly ordered by the site maintainers (literally you tack a number on to the addin folders name. So the Indexette addin running at ode.io is installed as 04Indexette. Ode recognizes a number of a number of addin routines:
01. inventory_ping_response,
02. replace_discover_posts,
03. replace_find_req_theme,
04. replace_interpolate,
05. replace_posts_sort,
06. manipulate_request,
08. pre_filter_posts,
09. filter_posts,
10. access_head_theme_early,
11. access_date_theme_early,
12. mod_post_file_before_read,
13. access_title_tags_and_body_early,
14. access_posts_theme_early,
15. access_foot_theme_early,
16. access_page_late,
Any addin can implement any or all of these routines. The only one required is inventory_ping_response. Ode runs through the addins directory and for each addin it finds it calls the inventory_ping_response routine to ask the addin if it should be run. If yes, Ode remembers which of the other routines are implemented. As Ode runs it gets to the point where all of the manipulate_request routines for example should be run. It then calls the manipulate_request routine for each addin that includes one in order. Each subsequent addin is unaware that earlier addins have run. There is no intermixing of addins.
It is true that there can be conflicts. For example replace_posts_sort changes the way that Ode sorts all of the posts for the site. If you had two addins installed both implementing a replace_posts_sort routine, the last one would win. The first one would change the sort routine, and the next would change it again, and then the posts would be sorted.
That's about it.
Content is stored in plain text files organized into folder hierarchies, just like a static site. The only difference is that the post files are just content, not all of the HTML that forms the framework of the page (duplicated for every file as you'd have with a static site).
Themes are separate from content. The posts are plugged into the theme.
Addins are completely separate. There are no references to addins in themes or vice versa.
It could be that an addin requires a specific theme be installed (along with possibly many others). For example the editedit addin allows posts to be edited in a browser. It comes with it's own theme that includes the form fields necessary to input the changes. So the theme is the interface for the addin. But then that special theme is just part of the addin.
As for Wordpress. I don't like it. :)
Here you go @john_henry_twitter https://ode.io/downloads/ode_releases/ode_current.zip
I wouldn't call it an alpha. It's the old version. It should work fine. There are detailed instructions included. You should only need Perl to get it going. Let me know if you have any trouble. Once it is running it shouldn't give any trouble. The few installs that are out there have been running for years.
Yep that makes sense. It has to write that file(s) so requires write permissions to the Indexette directory. In general you should expect an addin that uses a state directory like that to require write permission to it's own directory. (But not the state directory itself.) The only thing that should ever access those individual state directories is the addin itself. That is assuming no one modifies the addin or script. So the addin and the script are in other directories, without write access and are (should be) themselves not writable.
This site moved. At NearlyFreeSpeech.net, you don't need to buy a domain. I'm using the default domain to experiment with https w/o having to deal with certs:
The goal is to rewrite it without changing how it works, adding a couple of features to the core of the script. Doing a Perl and JS version.
I'll feel good about that.
There are a bunch of different ways Ode could be optimized. That would be fun, tweaking it to make it faster and more scalable. I'm sorry I haven't gotten around to it.