Show HN: Hosty – Image/Text self-hosting for minimalists in PHP(bitbucket.org)
bitbucket.org
Show HN: Hosty – Image/Text self-hosting for minimalists in PHP
https://bitbucket.org/xrstf/hosty
23 comments
You missed MediaCrush ;)
https://github.com/MediaCrush/MediaCrush
Building your own is easy and fun, though, I don't blame you.
https://github.com/MediaCrush/MediaCrush
Building your own is easy and fun, though, I don't blame you.
Sometimes I’m missing the Good Ol’ Days. You know, when you where able to download some PHP files as a ZIP, extract them, maybe change some configuration and be done. You didn’t have to bother with a bunch of other tools just to get some script ready.
(This is, by the way, no offense to this project at all! I just couldn’t resist to write this.)
(This is, by the way, no offense to this project at all! I just couldn’t resist to write this.)
I agree. For such a simple script, requiring all these tools (npm, bower, composer, grunt), it just doesn't seem practical.
Is this how people develop and deploy PHP stuff nowadays?
Is this how people develop and deploy PHP stuff nowadays?
Aside from Composer (which is a good thing for managing dependencies), I'm not sure why you would think "this is how people develop and deploy PHP stuff nowadays". The author uses these tools out of choice, not convention. Just like some Ruby devs use Bower and others don't.
For the life of me do not understand why anyone would require Node's package manager as a requirement for a PHP application.
One of the few strengths of PHP is that there doesn't have to be a "build process."
You don't even have to compile CSS and JS, really, but I guess people aren't comfortable with js or css which isn't machine generated. Fair enough - there are benefits to that, but as general practice, it's needless complexity.
One of the few strengths of PHP is that there doesn't have to be a "build process."
You don't even have to compile CSS and JS, really, but I guess people aren't comfortable with js or css which isn't machine generated. Fair enough - there are benefits to that, but as general practice, it's needless complexity.
It's a build requirement, not a requirement to run the app. If you know a better way to install grunt-contribs, please tell me.
I made it more obvious in the readme that you do not need build tools to run Hosty. Seems like that confused a lot of people.
I made it more obvious in the readme that you do not need build tools to run Hosty. Seems like that confused a lot of people.
> If you know a better way to install grunt-contribs, please tell me.
I would just not use grunt. I understand it's not required to run it, but even as a build dependency, unless you already have Node installed and running, it's a lot of overhead for relatively little benefit, I think.
I would just not use grunt. I understand it's not required to run it, but even as a build dependency, unless you already have Node installed and running, it's a lot of overhead for relatively little benefit, I think.
I'm on the fence on this one. On one hand, I'm fond of package managers. On the other, there's a TON of crap every time I run bower install... I've yet to figure out the best way of doing things. I'm thinking of using bower-installer, ship with a copy of the assets, and include bower.json, but not bower_components/. The other alternative is obviously CDNs, but then you're maintaining assets manually
PHP already has a package manager though (Composer.)
Granted, the amount of friction involved depends on personal preference, and whatever environment you're working in, but why require a package manager in another language (and, potentially, the language itself) when one exists for the language you're actually deploying in?
Granted, the amount of friction involved depends on personal preference, and whatever environment you're working in, but why require a package manager in another language (and, potentially, the language itself) when one exists for the language you're actually deploying in?
I'm sympathetic to your point. Where I work, we use Grunt and npm for our PHP projects, and I'm in the process of replacing them (slowly but surely) with PHP-based versions of the tools we use, and replacing Gruntfiles with Makefiles. It's experimental, currently, but I feel like it's doable. The only dependency then is PHP and Composer, which I think is nice.
I include bower_components/ in .gitignore and use grunt-bowercopy[0] to move the files you actually want from bower_components/ to public/{js,css} or wherever. Files get committed once they're in public/ and I only re-run the grunt task when I want to upgrade a lib. I can understand people thinking this is overkill for a small project, but when you have dozens of libraries it's nice to have dependencies and their versions clearly defined.
[0]: https://www.npmjs.com/package/grunt-bowercopy
[0]: https://www.npmjs.com/package/grunt-bowercopy
I agree with the other reply -- this isn't so much of an indictment of PHP, as it is front-end development in general.
Sure, to keep it simple you could download your JS and PHP deps once and bundle them all up in one nice zip. I think many apps provide a "dist" or "release" bundle (this one, in fact, does) in which you don't have to care about Composer, Bower or npm. However, to properly organize deps or define build processes for development, why not use some of the (frankly) common tools available?
It's funny how HN could see a simple unzip-and-go app and scoff "amateur hour hobby project". But if someone takes a more formal approach to their hobby app it can flip and scoff "over-engineered bloated setup".
Sure, to keep it simple you could download your JS and PHP deps once and bundle them all up in one nice zip. I think many apps provide a "dist" or "release" bundle (this one, in fact, does) in which you don't have to care about Composer, Bower or npm. However, to properly organize deps or define build processes for development, why not use some of the (frankly) common tools available?
It's funny how HN could see a simple unzip-and-go app and scoff "amateur hour hobby project". But if someone takes a more formal approach to their hobby app it can flip and scoff "over-engineered bloated setup".
Things got more complicated when I decided not to just use CSS/JS from some CDN, but have it locally available. Then I needed to postprocess the CSS to remove @include rules.
Most of the build process is meant to create small, versioned files, so users don't need to download full jQuery/Bootstrap stuff. I would feel bad for not optimizing my assets.
Most of the build process is meant to create small, versioned files, so users don't need to download full jQuery/Bootstrap stuff. I would feel bad for not optimizing my assets.
Oh, I fully agree with how you have everything set up and organized. It's clear you tried to be as formal as possible with organizing the app, it's dependencies and build processes, for _development_. People are just misunderstanding that bit or nitpicking. Like I said, it's damned if you do, damned if you don't.
Don't sweat it, people would've complained either way. Like you said earlier, it's a build requirement, not a runtime one, and there are advantages to using these tools.
It's actually pretty pratical if you already have those tools installed.
That's why I do provide pre-packaged ZIP files, which don't require you to have npm, grunt, bower or Composer. ;-)
As said, wasn’t at all about your project. But I’m glad you made this more clear. :)
Hastebin (written in Node) is also cool if you intend on making it public - I put an instance up at https://paste.ian.sh and I use it every day.
Looks good. Bepasty looks similar also, however not sure if it supports fully public url's.
I then looked around for existing, simple self-hosting tools, but all I found where huge near-community apps like Gallery2, Coppermine, ownCloud or ownstagram (with commenting, rating, folders, tags, ...) or PHP scripts from before there was PHP 5.
Long story short: None of them fit my need, so I built my own. It's based on Silex (Symfony2's micro-framework sister) and Twig and only offers the bare minimum. Files are placed in the local filesystem, a database is not needed. Apache2 is the default supported webserver, but we have Hosty in production using nginx over SSL as well.
Uploading is only allowed for registered users (and users have to be configured in a config file), viewing is allowed to anyone having the link to a file. It's not intended to be a public file hosting service, so do not try to add some public register form or something like that ;-)
Hosty can be used inside a LAN without Internet access; no external resources are being used. It's published under MIT and deliberately doesn't add any promotional links or "Created by Hosty" footers.