Running Gallery3 on shared system with Nginx, no webserver config access
229 views
Skip to first unread message
Stian Lund
Mar 15, 2021, 6:13:42 AM3/15/21
to Gallery 3 Users
Hello!
First thanks a lot to the Gallery Revival team for keeping this software updated :)
I've used Gallery on my site since 2001 or so, and it's worked mostly flawlessly for my use. However lately my shared webhost (SDF.org) has (stupidly) decided to move from Apache to Nginx, even when it's clear that Nginx is not well-suited to shared hosting: No .htaccess files users can edit per directory.
This results in requests for the combined CSS files for Gallery returning a 404, as well as most URLs like the login and update pages also giving 404s.
I've tried searching the documentation and config files to see if there's a way to turn off URL rewriting for Gallery, leaving ugly but at least functional URLs. I see there's several posts about Nginx here, but it looks like these have access to the Nginx server configuration, something I do not.
I've also tried a completely clean install dir and database, and the same happens, so I don't think it's a setting in the DB I've changed.
Is there any way to turn off the requirement for URL rewriting or any other workaround for this issue without needing to edit the server config files?
regards,
Stian
Brad Dutton
Mar 17, 2021, 1:40:09 PM3/17/21
to Gallery 3 Users
As you mentioned a few people have posted various Nginx configs for gallery. I started the gallery docker container using Nginx and PHP FPM as that's how I run most of my PHP docker containers:
But gallery is setup to operate under Apache. The permissions require .htaccess to be enforced, the gallery code checks if .htaccess files can be created/used. Basically if you use permissions on your gallery all image requests will have to be routed through the app instead of using the native web server file handling. The next version of the gallery docker container will be switched back to Apache.
Back to your specific issue, if you leave index.php set for the index_page setting in config.php you will keep the ugly URLs. I'm guessing your hosting probably passes the PATH_INFO information if they configured you for PHP FPM & Nginx so I would guess things should work, but I haven't tested this.
Brad
Stian Lund
Mar 17, 2021, 3:43:01 PM3/17/21
to Gallery 3 Users
Hello Brad,
Thank you for the reply.
> But gallery is setup to operate under Apache. The permissions require .htaccess to be enforced, the gallery code checks if .htaccess files can be created/used. Basically if you use permissions on your gallery all image requests will have to be routed through the app instead of using the native web server file handling. The next version of the gallery docker container will be switched back to Apache.
Like you say, I suspect that Gallery is written with Apache + htaccess in mind and while it can be run in Nginx with the correct configuration, it was never meant to be run in anything but Apache.
> Back to your specific issue, if you leave index.php set for the index_page setting in config.php you will keep the ugly URLs. I'm guessing your hosting probably passes the PATH_INFO information if they configured you for PHP FPM & Nginx so I would guess things should work, but I haven't tested this.
I didn't think about config.php, don't think I've ever had a need to edit it in all the time I've used Gallery.
I assume you mean this line?
$config["index_page"] = isset($_GET["kohana_uri"]) ? "" : "index.php";
Not sure what to do here, this is just the default, I never touched it.
It would probably help if I posted posted the URL to the site:
As you can see, no CSS or JS, and most if not all links lead to a 404.
Even links like this below, which I believe is not using a rewrite:
The most obvious problem is of course that the combined CSS (and JS) fail to load:
But the problem goes much deeper than that, even if I somehow get it to not combine the CSS/JS.
I've also created a phpinfo if that helps: https://stian.sdf.org/gallery/phpinfo.php
regards,
Stian
Brad Dutton
Mar 17, 2021, 4:29:56 PM3/17/21
to Gallery 3 Users
The PATH_INFO details have to be configured in nginx:
That shouldn't generate a 404 but instead needs to pass somepathinfo as the PATH_INFO variable to the index.php script. If you can't make nginx configuration changes I'm afraid this won't work.
Stian Lund
Mar 17, 2021, 5:37:29 PM3/17/21
to Gallery 3 Users
On Wednesday, 17 March 2021 at 21:29:56 UTC+1 Brad Dutton wrote:
That shouldn't generate a 404 but instead needs to pass somepathinfo as the PATH_INFO variable to the index.php script. If you can't make nginx configuration changes I'm afraid this won't work.
Hello Brad,
I was afraid of that. I might get the system admin to add something to the Nginx configuration as long as it's *very general* and won't cause issues for other users on the system.
If so what should I tell them to add? It can't be on my site config but something for all users, they just can't be bothered with specific user config, but if I ask nicely they might be willing to change something on the server.
Also, are there some simple changes I could do to the Gallery PHP files myself, like setting a variable in index.php or similar to override any missing server variables? Gallery isn't updated that often so I should get by as long as I keep track of the changes I've made.
cheers,
Stian
Stian Lund
Mar 17, 2021, 5:46:50 PM3/17/21
to Gallery 3 Users
In addition, I've been able to figure out that if the URLs are changed by adding "index.php?kohana_uri=" like this then it doesn't throw a 404:
index.php?kohana_uri=/combined/css/e250f7fd83043e7c348b435d0fa0a70c.css
index.php?kohana_uri=/login/ajax
So how would I make Gallery just use the "kohana_uri" style URLs?
Stian
Brad Dutton
Mar 17, 2021, 6:23:48 PM3/17/21
to Gallery 3 Users
You can try:
$config["index_page"] = 'index.php?kohana_uri=';
in application/config/config.php
Stian Lund
Mar 17, 2021, 6:40:03 PM3/17/21
to Gallery 3 Users
On Wednesday, 17 March 2021 at 23:23:48 UTC+1 Brad Dutton wrote:
You can try:$config["index_page"] = 'index.php?kohana_uri=';in application/config/config.php
Thank you so much Brad, now we're getting somewhere! :)
Actually I was thinking something similar but I tried:
$config["index_page"] = isset($_GET["kohana_uri"]) ? "" : "index.php?kohana_uri=";
Which only works for the first request, after that I still get a 404, I guess because kohana_uri is set?
Trouble now seems to be that if I try to do anything complex like admin stuff I get the dreaded "Dang... Something went wrong!" page...
"The requested views, admin.html, could not be found"
I can login though, but logging out gives the error page.
"The page you requested, logout?csrf=836f4f7688ac9fce82eedf092deab2d1?continue_url=https://stian.sdf.org/gallery/index.php?kohana_uri=/, could not be found."
Trying to view images or albums just gives a blank page. Seems it throws a lot of errors in the background.
cheers,
Stian
Gwyneth Llewelyn
Mar 20, 2021, 7:52:02 PM3/20/21
to Gallery 3 Users
Hi all,
But Apache is not the 'best' tool for all situations. New generations of applications run their own, internal, minimalistic web server, and expose it conveniently through a port. While you can certainly use Apache as a front-end for those applications, it's really overkill, when there are plenty of alternatives around to provide a modern, secure and efficient front-end web server to relay things back to an application running in the backend. Nginx is just perhaps one of the oldest of such solutions, and possibly the most battle-tested by far, but it's not the only one. Indeed, Nginx, since its very beginning, has never supported PHP 'natively' — PHP has always to be run as a backend service (through PHP-FPM or a similar solution). The advantage, of course, is that you can cleanly separate front-end HTTP-related issues from backend considerations (such as pretty URLs and/or permissions...). Ideally, those things should be completely separate and not 'integrated' as if Gallery (or any other application) is just a strange extension or addition to Apache, as opposed to being a standalone application.
Gallery3 runs on top of the now defunct and obsolete Kohana Framework. While arguably there is at least a valid successor fork (Koseven) which seems to continue to be maintained (the last update was just a week ago, which is a really good sign), and eventually Gallery3 might be moved from Kohana to Koseven and thus guarantee some degree of future-proof-ness, I think that one ought to leverage on the framework to do whatever internal routing is necessary, as well as placing all safeguards in place, and not rely on 'external sources' for that. Granted, I'm not really used to Kohana — nor to any popular PHP framework, to be honest — so I cannot claim to know how easy it is to work with that framework in particular. But for those who are serious about continuing to develop Gallery3, I would seriously encourage you guys to work strictly within the constraints of the framework. The whole concept of having a PHP application tinkering directly with .htaccess files makes me cringe — that's how a company I worked for did things in 1998, and lived long to regret such decisions. It could be worse, of course — it could be happily writing Apache vhost configuration files instead, or, why not, directly accessing /etc/passwd to create and remove users (aye, that's one of the many ways we did things back in 1998 in a hurry...).
Similarly, while I understand the concept of storing images in quasi-hidden, obscure directories, with complex access paths — and I can even agree that those might make sense in a scenario where users are not supposed to view certain images, such as in a system behind a paywall — it's also true that something will go wrong at some point when using that concept. Files get lost — the database loses track of where certain files are supposed to be — things get out of sync, and so forth. You need to deploy maintenance tasks to figure out where the 'missing files' have gone, and try to update the database accordingly; similarly, the database must be pruned once in a while, in the case that it got corrupted, was restored due to a database server error, and now contains pointers to images stored on disk that don't exist anymore — or someone made a mess of the image folders, uploaded things directly to them, and 'forgot' to tell the database about the changes...
Not even mentioning that you have to forfeit a lot of optimisations — the kind that didn't exist in 1997: CDNs, different ways of compressing images on disk, different levels of caching (on-premises, on the cloud...), direct static access to images bypassing the actual engine running the application, load balancing, and so forth. In a sense, many programmers are so deeply in love with the abstract, virtual environment provided by their favourite language or framework that they forget that, these days, contemporary operating systems have incredibly efficient filesystems — it's stupid to 'reinvent the wheel' in hope of being able to 'beat' the filesystem and develop something 'better'. This might have been the case a few decades ago, when disks weren't so fast and many filesystems were not necessarily optimised as they are today. I'm actually quite amazed that, these days, there are a few programmers out there who have figured out that storing a whole CMS on disk and not on a database gives blindingly fast performance; just because modern CMS are supposed to be 'dynamic' and not 'static', that has little relevance to how things are actually stored. In other words: don't 'fight' the filesystem by trying to be more clever than it. The filesystem is your friend, your ally — not something which has to be crushed or at least ignored. Leveraging on the filesystem itself means that front-end applications such as nginx, Varnish, or even CloudFlare (to mention three different levels) can efficiently cache content all the way — to the very browser itself. Remember, a faster algorithm always beats a faster machine — throwing hardware at a problem in order to 'fix' it just means that it has been sloppily programmed. One thing that I've always loved about Gallery is that it is — and always has been! — very fast, even on old, underpowered systems. I'm assuming that when Gallery was first developed, and Kohana became the choice of framework, the original developers didn't have racks and racks of servers to deploy their application, so they just had to use whatever underpowered device they could grab to do a few tests.
Last but not least... I'm well aware of the current trend (started by Google!) of distributing everything as a Docker container (or, well, some other sort of popular container). The theory is that 'things are too difficult to configure anyway' so developers will carefully pick a working combination of software layers and just ship those as an opaque container. That's all good — and most certainly has lots of uses! — but it has two terrible disadvantages.
The first, of course, is performance. Docker containers and similar technology is appropriate for cloud-based computing, which is virtual anyway, and 'performance' is just a question of moving a slider to get more CPU, RAM, disk space, and number of instances — and get charged accordingly. If everything is properly inside a container, it makes all the work of distributing software around a true blessing — no need to hunt down for 'rogue' instances still running the 'wrong' software stack and throwing errors. But if you're paying for just a single server to host your own content, containers are just another virtualization layer on top of the 'bare metal' running beneath, sucking up precious resources. One may argue that, in practice, container technology is so advanced in 2021, and gets so much help even from CPU instructions specialised for virtualization, that this overhead is negligible. This might be true in some scenarios, but, from my experience — and not from looking at someone else's benchmarks! — this is hardly the case. I run Docker once in a while on my Mac, when I really need to launch some sort of application that is not 'easy' to install (for instance, because some elements of the required software stack are not readily available, and it's far too much work to simply compile them all from sources), especially when it's something I'll use seldom or that I'm just evaluating. Sure, the time saved in skipping all the requirements and running the container without worries more than compensates the eventual lack of performance (hint: when running Docker on my Mac, it's pointless to try to run anything else — especially during the actual container launch/activation. Sure enough, when the application(s) inside are pretty much idle, Docker will not really hurt performance; then again, if I'm launching something inside a container, it's not because I want it idle all the time, but rather because I want to use it...).
The second disadvantage is a far more complex one. By making a container opaque — i.e. a 'black box' which 'just works', no assembly required — the end-user has no clue if the actual software choices and configuration details are optimised for their particular hardware or use-case. It also becomes much harder to figure out if all components inside the container are up-to-date and have no serious security issues — especially the kind of issues that are not present when running the container in complete isolation, in a lab, but which become apparent as soon as that specific container is dropped inside the complexity of a server probably running a lot of different systems (again, this is not the recommended way of configuring cloud-based solutions, and that's why containers are so great for those — in theory at leasy, each computing instance ought just to run one container with one application/service inside; if you need to run anything else, place it on different instances, and make sure they don't conflict with each other; if they do, well, you can isolate the rogue instances easily enough).
Imagine the following scenario (which is almost not hypothetical but very close to reality): on my admittedly underpowered server, MariaDB is basically the huge resource hog — mostly because I'm at the mercy of WordPress plugin developers who think that logging everything to the database is a 'good idea'. As a consequence, almost every resource has to be given to MariaDB (CPU and RAM...) while the remaining processes — doing pretty much everything else — have to share a few scraps that remain. Now let's assume that the Gallery Revival developer team decides that MariaDB is not really a 'good enough' replacement for MySQL, because there are one or two quirky (but much needed!) features which won't work under MariaDB (which I don't need to remind you that has been developed well after Gallery was first released...). Since the work to refactor the code to take those 'quirks' in account — or rather to avoid them in order to support more databases which are compatible with the MySQL wire protocol (such as, say, Amazon Aurora, Google Cloud SQL for MySQL, or even a DIY-MySQL-compatible-RDBMS) — might be too much effort, the developers decide to bundle MySQL itself within the same Docker container. Now my poor underpowered server not only has to deal with two different web servers but with two different database systems — not to mention the extra overhead from 'dockerizing' this container... all that for running a software which is showing its age and could be replaced by placing every image/movie on Flickr (or anything else) and forget all about running one own's server...
In conclusion: I love when developers in the community add an optional Docker container for download. This is because in many cases, the majority of support requests/questions are not connected directly to the application itself, but rather to the environment it's running on. Since people can have a vast variety of quite different environments, trying to answer all possible environment-related questions may be close to impossible — which can also be perceived by potential future Gallery users as a software which might be useful, but which has a worthless community of developers and supporters. Open-source software that has a friendly, engaging community, which is always ready to step in and solve issues, is seen generally as a more interesting alternative (as opposed to single-developer solutions where the developer never answers any of the requests). This trade-off is often easily solved by using some sort of virtualization technology and tell potential users to simply install the container and start adding images and videos to it — thus 'proving' to them that the only problem they have is with their environment, the application itself is working nicely.
Thus, I certainly encourage and welcome an always-up-to-date, but optional, Docker container for Gallery Revival.
However, because Docker containers (or any other virtualization technology) have their drawbacks — for me, the most important one is knowing that just one 'magical' environment is the 'correct' one for running that specific application, which means that something must be wrong with it — getting the application to run outside of the container should always be an option — even if it might be something hard to do for the user. In other words: the priority should be to install the PHP source on one's system and it should work under most scenarios; if it doesn't work, then you can always use the Docker container (while eventually figuring out what is so different in your environment that the application doesn't run).
Anyway, please apologise my ranting. It's just that I have gone through similar scenarios so often (even WordPress is 'guilty' of the same mistakes, especially in a multisite environment...) that I'm well aware of the nightmare it is when things go wrong. I have experimented with some applications that have 'decided' to only support running inside a specific container technology, exactly because they were tired of answering way too many questions about the running environments. I remember one case where the developers even offered the original source code, for those — like me — who were masochistic enough to run the code outside of a container of some sort. Not only it was a nightmare to set up — the insane amount of frameworks it required just for basic functionality was mind-boggling — but, at the end, it did not work (or at least most of the functionality wasn't working), basically because the application was so badly written, with horribly-patched legacy code, and a development methodology which was stubbornly 'reinventing a lot of wheels' without any practical purpose except making the installation tasks even harder... and 'forcing' potential users to give up and just run the container version instead.
Admittedly, I'm possibly over-reacting here; but when I first started to use Gallery — and still do! — was because it was a simple, easy-to-install solution, taking few resources, and was super-fast. When considering alternatives — such as Flickr! — I tend to evaluate them compared to Gallery: what else do they offer that Gallery doesn't, and what kind of resources will I need to run such alternatives? (Needless to say that this makes me reject anything running on Java or Ruby on Rails...) So far — and I admit I haven't been 'shopping for alternatives' lately — Gallery, even with its many shortcomings (such as an integration plugin with WordPress which is now hopelessly outdated and requires a lot of effort to get it to work), beat the alternatives. But from what I've read on this thread, things may start to become intolerably complicated in the very near future, and that's Not A Good Thing.
Ultimately, if the development guidelines for Gallery are departing too much from what made it so attractive 15 years ago or so, I guess it's time for me to move on to Coppermine — which I did use extensively a decade ago for a 'special project' for a customer requiring access to a photo gallery that had some form of API. At that time, Coppermine was much more suited to the task than Gallery, so I had to admit that I had to use Coppermine instead. Coppermine, BTW, is still being actively developed. It allows fancy things such as single-sign on by sharing login data with a dozen or so applications; it's easier to tweak/change the theme or develop one's own theme; and, as said, has (had?) a more documented API for better integration. Why I'm not using it instead of Gallery?... well, there are many reasons, but I'd say that 'bad code' would be at the top: while I'm not a huge fan of 'frameworks', Gallery has the advantage of being just an application running on top of Kohana, and Kohana, by itself, provides pretty much everything needed to develop a full application — one that runs very fast thanks to the many levels of caching and very clever code optimisation. Coppermine does 'everything from scratch' and not necessarily in the best way possible; some programming decisions, made very early on, affect the whole development process, and it's hard to change the overall conceptual architecture, since Coppermine depends on it. Gallery — in theory — changes easily if Kohana is changed; granted, the lack of further development of Kohana is a real problem, but, as said at the very beginning, it might be relatively easy to 'port' it to Koseven or whatever Kohana fork is chosen, and enjoy a continued development at the core level at least, leaving the community of Gallery Revival developers free to focus on the essential features they wish to implement on the application itself...
Anyway... enough from me. I know; I talk too much. But I only do so with things that I'm truly passionate about; I have been a huge fan of Gallery, even when there was no 'Revival' in the horizon. Now, of course, I'm even more passionate, knowing that, at least, there is the will to pursue this project further!
Thanks again for all your volunteer work to keep this project alive, and please disregard an old loudmouth.
Cheers,
- Gwyn
Gwyneth Llewelyn
Mar 20, 2021, 8:11:35 PM3/20/21
to Gallery 3 Users
More to the point...
I 'fixed' the URL issues simply with
$config["index_page"]="";
Weird, isn't it? But I had the exact problems you have, and that incredibly simple change fixed everything under my own nginx configuration.As for the relevant nginx configuration itself, this is pretty much what is not default from typical vhosts running PHP:
index index.php;
location / {
location ~ /(index\.php/)?(.+)$ {
try_files $uri /index.php?kohana_uri=$2&$args;
location ~ /var/thumbs/.*/.album.jpg {
}
location ~ /\.(ht|tpl(\.php?)|sql|inc\.php|db)$ {
deny all;
}
location ~ /var/(uploads|tmp|logs) {
deny all;
}
location ~ /bin {
deny all;
}
location ~ /var/(albums|thumbs|resizes) {
rewrite ^/var/(albums|thumbs|resizes)/(.*)$ /file_proxy/$2 last;
}
location ~* \.(js|css|png|jpg|jpeg|gif|ico|ttf|svg|bmp|pdf)$ {
try_files $uri /index.php?kohana_uri=$uri&$args;
expires 30d;
}
}
location = /index.php {
include fastcgi_params;
fastcgi_index index.php;
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_pass unix:/var/lib/php7.3-fpm/web23.sock;
fastcgi_intercept_errors on;
fastcgi_buffer_size 128k;
fastcgi_buffers 256 16k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_max_temp_file_size 0;
fastcgi_read_timeout 7200;
}
}
Adjust fastcgi_pass according to your own setup.
Note the location-inside-location-inside-location way of dealing with the awkward Kohana URIs; it's the first time I saw something so confusing! But, alas, all my attempts to 'simplify' the nginx configuration — much in line with what Brad did — to make it look more 'normal' have failed; then again, the rules above, although they are an eyesore for humans, are actually parsed very efficiently by nginx (no ifs!).
I understand that you're unable to get access to the nginx server files? There is no way for you to at least add a few rules to the vhost's configuration? (I use a control panel application to manage my own vhosts; most of the configuration is also 'set in stone', but I've got a way to add more rules beyond the default ones in the vhost template.) This will make it very hard to run Gallery! And I'd guess that you won't be able to run it from a Docker container either...
Hope it helps.
- Gwyn
Stian Lund
Mar 21, 2021, 7:28:42 AM3/21/21
to Gallery 3 Users
On Sunday, 21 March 2021 at 01:11:35 UTC+1 Gwyneth Llewelyn wrote:
I 'fixed' the URL issues simply with$config["index_page"]="";
Weird, isn't it? But I had the exact problems you have, and that incredibly simple change fixed everything under my own nginx configuration.
If I do that then it returns to give 404s for everything but static resources. Including the auto-combined CS and JSS files.
The really strange thing is that while no albums show on the main Gallery page, I can actually log in, and then I can browse and even change basic album stuff. But a lot of pages are still broken, like the admin pages and others. Being logged in Gallery gives me the "Ouch..." page with information on what broke and it seems there's still internal 404s and pages not found.
I understand that you're unable to get access to the nginx server files? There is no way for you to at least add a few rules to the vhost's configuration?
Yes - I can *read* /etc/nginx but I can't change it. It's a shared system so all server configs are in the same file. I've asked the admins if there's a way to break the config up into separate snippets and let us edit them. Problem with Nginx is that a single error in one such file would abort the whole server and all sites from loading...
The current vhost config for my site in /etc/nginx/sites-available/default (I removed some not relevant stuff):
server {
listen 80;
listen 443;
server_name stian.sdf.org;
index index.html index.php index.cgi;
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.3-fpm-stian.sdf.org.sock;
}
location ~ \.cgi$ {
gzip off;
fastcgi_pass unix:/var/run/fcgi/stian;
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
location ~ {
autoindex on;
}
}
The snippets/fastcgi-php.conf:
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
# Check that the PHP script exists before passing it
try_files $fastcgi_script_name =404;
# Bypass the fact that try_files resets $fastcgi_path_info
# see: http://trac.nginx.org/nginx/ticket/321
set $path_info $fastcgi_path_info;
fastcgi_param PATH_INFO $path_info;
fastcgi_index index.php;
include fastcgi.conf;
So it does look like PATH_INFO is being set but SCRIPT_FILENAME is missing, maybe I can ask the admins to add that but I really have no idea if it would help at all. Like I said I can't ask them to add anything specific for my site, it would have to be general for all sites and not cause any issues.
As for your ramble earlier, I definitely understand :)
Gallery is old and even with the revival code there will probably be a limit to how long it can work as PHP and web servers change. I've used Gallery for nearly two decades now without any big issues, keeping it mostly just to the defaults, just adding some themes and other modules.
At the moment I'm considering switching web hosts, which would suck as SDF is a great place, one of the few "BBS-like" communities left on the net. Except the new admins are being dicks about stuff and the change to Nginx was completely unneeded and has caused a lot of problems like this, but they refuse to change back to Apache for "performance" reasons which is B-S.
regards,
Stian
JR
Mar 21, 2021, 2:22:19 PM3/21/21
to gallery...@googlegroups.com
Gwyneth,
That is a great write up of
what *could* be done to truly "modernize" Gallery 3, but,
uh... you seem to be under the impression that there is a
formal Gallery development group at work -- unfortunately,
that has not been the case since the original development
group disbanded almost 7 years ago back in 2014. Per the old
Project Development site at http://galleryproject.org/ ---
"The Gallery team has decided to take a step back from actively maintaining this project. Truth be told, most of the core team got busy with their lives over the past few years and we haven't had the time to really actively maintain the project in a long time. The forums have continued to be lively and helpful and there is still plenty of good conversation there - but no new code has been written in the past 6 months and that's not likely to change."
What we have going here is a group of
knowledgeable gallery *users* who liked Gallery 3 so much they
decided to see what they could do to keep it running when the
internet moved to PHP 7 (which the last official 2014 Gallery
3.0.9 release will not do). Adobe cancelling all support for
Flash made it necessary to also develop a new image uploader
which does not rely on Flash like the uploader in 3.0.9 did.
Other updates were necessary to keep jquery running well. There
are some other ongoing tweaks to get some of the older modules
running in the current 3.1.3 release and to develop a responsive
theme. The prime mover in this effort is Brad Dutton, which help
and suggestion from others.
But this all comes under the heading of "upgrading". Completely re-creating Gallery 3 from scratch is simply not in the cards. Ultimately, there are now so many modern Gallery-type programs which have been created in the last 6 years that it wouldn't really make sense to do so.
-- J.R.
--
WHEN USING AN EMAIL PROGRAM to reply to this message, click REPLY TO LIST or REPLY TO ALL so your reply goes out to everyone in the group. If you click REPLY or REPLY TO SENDER Google will *only* send your reply to the original author (not recommended).
To post a NEW MESSAGE to the group, send an new email to:
gallery...@googlegroups.com
To view or sign in to this group on the web, use this URL:
https://groups.google.com/forum/#!forum/gallery-3-users
---
You received this message because you are subscribed to the Google Groups "Gallery 3 Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gallery-3-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/329a35f6-8c53-4c01-8703-63c01a99a631n%40googlegroups.com.
Stian Lund
Mar 22, 2021, 12:52:45 PM3/22/21
to Gallery 3 Users
Hello - an update.
I was able to make a (rare) config change on the Nginx server. Basically the location parameters for .php was incorrect for FastCGI. The other stuff seems to have been OK, although I'm still very limited as to what I can change on-the-fly on the server side.
Still getting some errors that seem to be related to server config, when trying to edit album permissions I get:
"Oh no! Your server needs a configuration change in order for you to hide photos! Ask your server administrator to enable mod_rewrite and set AllowOverride FileInfo Options to fix this."
Any idea what I can do about that on Nginx? Anything I can do in php.ini (which I do control)?
Also getting "Request entity too large" when trying to upload more than one image, probably also a server setting.
Uploaded resizes also show the "broken image" image instead of the resize.
After such a long time being unused, and with the upgrade to 3.1.3 I do expect some more errors so will have to test and go through issues one by one.
I'll need to go through the modules/themes and deactivate anything but the defaults to make sure old modules don't cause issues.
But so far so good, thank you guys for the input. If you have any tips on the above errors it's much appreciated :)
cheers,
Stian
Brad Dutton
Mar 24, 2021, 10:32:07 PM3/24/21
to Gallery 3 Users
For the upload too large you need to increase the nginx upload size:
Brad Dutton
Mar 24, 2021, 10:44:50 PM3/24/21
to Gallery 3 Users
I don't think you'll find many disagreeing with you on all of these points but I will add a few things:
* While some of these features would be nice to have they take time and effort to implement. Last I checked I'm the only one working on things and it's basically a maintenance mode item for me.
* Gallery 3 is old. As JR mentioned it was left for dead some time ago. During this huge time gap many people moved on and there was obviously 0 maintenance and upgrades being done.
* Gallery is based on Kohana 2. Koseven is a successor to Kohana 3, so there is no easy upgrade to a latest framework version. Kohana 2 was last updated in like 2012 I think.
Stian Lund
Mar 25, 2021, 8:03:47 AM3/25/21
to Gallery 3 Users
On Thursday, 25 March 2021 at 03:32:07 UTC+1 Brad Dutton wrote:
For the upload too large you need to increase the nginx upload size:
Hello Brad, I was able to figure this one out and get the admins to up the upload size :)
I was also able to fix the other errors, apart from the error when trying to edit album permissions:
""Oh no! Your server needs a configuration change in order for you to hide photos! Ask your server administrator to enable mod_rewrite and set AllowOverride FileInfo Options to fix this.""
My guess at the moment is that this will simply not be available on Nginx as I believe Gallery relied on the .htaccess files for this stuff? Unless you have a workaround for Nginx? It would be nice to be able to set user permissions and hide albums, but I can also just don't upload very personal images to Gallery I guess :)
regards,
Stian
Reply all
Reply to author
Forward
0 new messages