Check my fork!

[ivan-avalos]

Hey! I had been looking for ultra-minimal micro-blogging software for quite some time, and today I came across Microblog, which seemed simple enough for my needs. My goal is to create a micro-blogging service for myself, where I can post only to myself, as I need a place to vent and express myself privately.

However, in order for Microblog to be useful to me, it required some taming. I removed ActivityPub and Twitter support, added a config parameter for the database path, fixed localhost deployments (for testing), and fixed other small things that were very broken (how could everything in lib/ even load with incorrect paths in the default config!?)

Here's the repository of my fork: https://git.avalos.me/microblog

Feel free to take what you wish from my fork.

[oelna]

Wow, you have clearly put a lot of work into this. I'm glad you like it!

Of course I mainly develop this for myself, and XMLRPC support or ActivityPub are aspects that I need for microblog to be useful to me. I am not an exceptionally competent programmer, but I have thought about the functionality a lot and most of the time I put in config options to turn things off, when I add something new. I have been thinking about why you felt the need to actually remove the code, instead of just disabling it. Your fork diverges quite a bit now. I like how it is very focused, but I also have to warn you: the support for custom themes is not exactly perfect and is an area I'm looking to improve in the future. Maybe you'd like to look into this a bit yourself too.

Database path config option is something I've been thinking about, too. I was leaning towards a randomized filename that is unlikely to be guessed and I hope to be able to build this at some point. If I am honest, a future plan is to ditch the config file and make it a web based setup process, similar to how wordpress does it. The idea being that people can simply clone the repo, open the website and fill in some setup info, instead of them having to mess with renaming the config files.

One reason for this is that I am terrible at keeping the config-dist.php and my actual config.php in sync! I'm glad you caught this and took the time to tell me about it. Thanks a lot for this!

Anyway, thanks again for putting in the time and I hope you get some enjoyment out of microblog. It started small and grew over time, but I always appreciate people taking it and making it work for them. Good luck! <3

[ivan-avalos]

Of course I mainly develop this for myself, and XMLRPC support or ActivityPub are aspects that I need for microblog to be useful to me. I am not an exceptionally competent programmer, but I have thought about the functionality a lot and most of the time I put in config options to turn things off, when I add something new. I have been thinking about why you felt the need to actually remove the code, instead of just disabling it. Your fork diverges quite a bit now.

Maybe just paranoia. I wanted to make sure that nothing slipped by, and my posts didn't end up accidentally federating or being available in a publicly accessible feed. I know I could have just disabled them in the config, but having a smaller codebase makes it easier for me to audit and rest assured that no one can read my posts other than me.

I like how it is very focused, but I also have to warn you: the support for custom themes is not exactly perfect and is an area I'm looking to improve in the future. Maybe you'd like to look into this a bit yourself too.

I'm okay with the current theme. I'm the only one who will see it, so I don't need to change it.

Database path config option is something I've been thinking about, too. I was leaning towards a randomized filename that is unlikely to be guessed and I hope to be able to build this at some point. If I am honest, a future plan is to ditch the config file and make it a web based setup process, similar to how wordpress does it. The idea being that people can simply clone the repo, open the website and fill in some setup info, instead of them having to mess with renaming the config files.

I don't think you should ditch the config file, but rather have the web based setup generate a config file that the user can easily manage later on, either with the web based setup or manually. It would be easier if the format was JSON or YAML, and didn't have any PHP boilerplate inside. I honestly think that the current PHP config is bloated, some of the code should reside in a non-config file.

Thanks for creating Microblog, looking forward to more features and cool stuff!

[ivan-avalos]

Also, make sure to also check the fix for localhost deployments that I also implemented in my fork:

config-dist.php:

-	'url' => 'http'.(!empty($_SERVER['HTTPS']) ? 's' : '').'://'.$_SERVER['SERVER_NAME'].dirname($_SERVER['SCRIPT_NAME']),
+	'url' => 'http'.(!empty($_SERVER['HTTPS']) ? 's' : '').'://'.$_SERVER['HTTP_HOST'].dirname($_SERVER['SCRIPT_NAME']),

HTTP_HOST also includes the port, so this will make it easier to test locally in any non-standard port.

all occurrences of this:

- $domain = ($_SERVER['HTTP_HOST'] != 'localhost') ? $_SERVER['HTTP_HOST'] : false;
+ $domain = ($_SERVER['SERVER_NAME'] != 'localhost') ? $_SERVER['HTTP_HOST'] : false;

Cookies are port-independent, so in this case, the port shouldn't matter and this variable should be false in all cases where localhost is the host, so use SERVER_NAME instead.

[oelna]

I have actually been reading up on the difference between SERVER_NAME vs HTTP_HOST for use in microblog several times now. I am still not 100% confident in when to use what, with SERVER_NAME being configurable (?). Using HTTP_HOST seems more reliable tbh. I have mostly used this StackOverflow post.

I might put the $domain script inside a function so it can be changed and adapted more easily in the future in case something breaks. But I'll also implement your changes for now, as your explanation makes sense.

I am thinking about using HTTP_HOST instead and simply stripping the port where it is not needed. The cookies were a great tip, thanks!

[oelna]

I ended up doing this. Hope it works okay. And should improve handling of IPv6 addresses, too, I guess?

microblog/lib/functions.php

Lines 9 to 19 in 761822a

	function get_host($preserve_port=false) {
	/* this makes a SERVER_NAME out of HTTP_HOST */
	$parsed = parse_url('http://'.$_SERVER['HTTP_HOST']); // scheme is only required for the parser
	if(!$preserve_port || empty($parsed['port'])) {
	return $parsed['host'];
	} else {
	return $parsed['host'].':'.$parsed['port'];
	}
	}