Shutter stack questions

Hi Adam, congrats on these 3 new stacks and the new site design. Looking awesome! :slight_smile:
Now to the questions regarding the Shutter stack:

  1. Batch Mode: It would be so great if we could set the source folder for the images completely by ourselves. This includes ommitting the folder named ā€œbatchā€. Why Iā€™m asking? Now, for years now Iā€™m used to utilizing Joes Total CMS to let my clients upload their images for their galleries. The caveat: everything has to take place in the folder named ā€œcms-dataā€, which is in the root of the site. If I would be free to exactly choose the path for the batch images I could place this folder inside the cms-data folder. Any chance youā€™re adding this option?

  2. Normal image mode: What about an option to not only use single images via drag and drop but also remote images (warehousing)? Hey, I know you can do it, since you already added this feature to Orbit 2 (ā€œRemote Image Slideā€), rightā€¦? :wink:

Thanks in advance for your answers and keep up your awesome work!

Best, Matthias

Hey there @RapidBase ā€“

Thanks for your compliments on the new stacks!

If youā€™re going through the effort to add individual URLs for each slide it is probably best to simply use batch mode. This is why I skipped that option. If Remote Images were used for individual slides youā€™d have to supply both a normal and thumbnail sized image URL. This means creating both images, uploading both to their separate locations and entering both into the slide settings ā€“ for each image slide. Makes more sense just to do a batch folder, IMO.

This isnā€™t likely something that I would change. The way it is setup currently is purposeful. It provides the user a known, reliable place to go to and find their images and cuts down on confusion and added complexity.

Sorry, I know this isnā€™t what you wanted to hear. Thereā€™s some limitations to how things need to work to ensure a good user experience as well as limit the number of ways a user can get themselves into trouble.

1 Like

Thanks for the quick reply, Adam. No problem with not hearing what I wanted to. :wink: There are workarounds for me: For example the superb ā€œRepositoryā€ stack from inStacks. Iā€™m quite sure I can point its directory to the ā€œbatchā€ folder of the Shutter stack, so that the client can then upload and manage his images this way. Just like Total CMS also the Repository stack has an option to automatically downscale uploaded images (which I think is very important). This way my clients can throw in images of some megabytes size which are then re-calculated for web-usage.

Hi Adam, I fully share @RapidBase opinion on your SHUTTER stack. Simply great. Just one think: would you consider including webp image format? (it saves significant amount of space)

ā€¦and I love foundry and alloy: moved the full site using this framework and the user response is more than positive. Congratulations !!! (the site https://www.aiace-italia.eu/)

I tried to load this site. It took over a minute for the home page. I tracked it down to at least one large png file (700k) and there are others. Check banner_image-167-34B.png. Using PS export to web and 50% quality I got it down to 47k and itā€™s indistinguishable from the original.

Apologies I have a very slow connection (ADSL maybe 2mbs on a good day) and wanted to have a look at the site.

Thanks wirrah, I appreciate your comments and will reduce the size (at high speed connection this was going unnoticedā€¦)

1 Like

Shutter would not be able to auto create thumbnails for this format unfortunately. Youā€™d need to do it all manually.

Additionally, from my perspective there are still browsers out there that are not that old that do not support WebP.

This is the info I found.
Webp is supported by: Google Chrome (desktop) 23+; Google Chrome for Android version 25+; Microsoft Edge 18+; Firefox 65+; Opera 12.10+; Native web browser , Android 4.2+ (JB-MR1); Pale Moon 26+.

It will not work on Safari and IOS (because browsers for iOS work on Safariā€™s WebKit engine). Iā€™m not sure about Chrome for IOS, but Firefox doesnā€™t work).

Consider this before using Webp.

Hans

ā€¦spent some time to improve performances. Hope now it should be better and much faster. Really appreciated your inputā€¦thanks

Much better! Down from 70 secs to 10 for the home page! My current speed is only 1.4mbps.

Iā€™m not sure thatā€™ll work @RapidBase. It looks like, from the video, that Shutter creates the /batch/ folder either at the root of the site, or the root of the page containing Shutter.

Repository lives in its own page not the root of the site, so for instance /repository/. It can only ā€œseeā€ folders and files inside itā€™s own folder. It can not view the root folder, or any other folder below itā€™s own level.

For instance. Letā€™s say the folder structure isā€¦

/home/
/home/shutter-page/
/home/repository/

Based on the video the /batch/ gets auto created at either /home/batch/ or /home/shutter-page/batch/

Repository will only be able to ā€œseeā€ files and folders in /home/repository/. Therefore, if Iā€™m thinking all this through correctly, it will not be able to interact with the /batch/ folder, no matter where it is.

I think the new version of Repository can see outside of itā€™s own folder, I think; not 100%, but regardless, if you were to set it up for a client to be able to use Repository to get access to /home/batch/ they are also going to be able to see all other folders and files on the same level, which is a really bad idea Iā€™d say!

Maybe Repository can be locked down to one particular folder, in which case itā€™s got potential, but otherwise, I donā€™t think itā€™s going to have legs. Which is a real shame, as as soon as I saw Shutter I started to think along exactly the same lines as you: Itā€™d make the perfect frontend gallery for a client managed portfolio, but without being able to set the entire path, Iā€™m not sure how itā€™d work.

Shutter does look nice, the killer feature is the way it makes its own thumbnails, so we need to get our thinking caps on and come up with a solution.

Of course, One option (for Alloy users) is for Shutter and the /batch/ folder to somehow get integrated into the Alloy Editor. :wink:

EDIT: Thinkingā€¦ If Shutter creates /batch/ at the root of the site, in theory you could call the the repository page ā€œbatchā€ then add in the additional folder path to Shutter. I think that would work. `maybe give it a try?

Although, this would add lots of other files and folders inside /batch/ which might upset Shutter?

EDIT EDIT: Another option, and potentially a really simple one, is to add a rewrite redirect to the htaccess file, sending all calls to /home/batch/ to /home/repository/batch/.

I know htaccess rules can handle all incoming traffic and redirect as required, not sure though if it can also handle all requests for particular URLā€™s from the page itself, ie. Shutter itself being redirected to the /repository/ folder.

A few options there, maybe try and let us know?

Curiosity got the better of me so I bought the stack and have been playing around with the htaccess idea, gonna say it donā€™t work.

I can break Shutter by using a redirect, in that it wonā€™t load anything, which itself shows htaccess redirects can effect URLā€™s requested on the page, but I couldnā€™t get a test folder with some images in, and corresponding thumbnails, to display.

Itā€™s possible I just got the redirect wrong, but I tried lots of versions and nothing worked. So, donā€™t think htaccess is the way to go.

Need to make doggie biscuits now, then will try calling the repository folder batch, see how that works out.

Bingo!

Call the repo folder ā€˜batchā€™ in RW and it all works lovely. You can go to /batch/ and you get the repo page, drag images into the shutter folder and Shutter will create the thumbnail and stick it into the thumbnail folder, you can also create additional folders in /batch/ using repository and it doesnā€™t seem to bother Shutter. So itā€™s a very workable workaround. Until maybe we can talk Adam into having a full user set path option :wink:

The caveat I guess is that repository, and of course the batch folder, needs to be at root, but Iā€™d suggest it normally always is anyway.

3 Likes

Hey Steve, thanks for your extensive research and testing. It seems you have found a solutionā€¦ :slight_smile:

So this way I can actually populate multiple galleries on different pages with content using a single instance of the repository stack (and the thumbnails are generated automatically)? That would be perfect and for me - at least in some cases - an alternative to a full-blown TCMS installation (although TCMS will surely remain my go-to CMS solution in the foreseeable future).

Ya, thatā€™ll work, I think. Just give each instance of Shutter a different folder name, ie. /Batch/gallery1/. /Batch/gallery1/ etc.

If my understanding of how Shutter works is correct, itā€™ll do the rest for you.

1 Like

Great, thanks Steve. :slight_smile:

Iā€™ve done my best to try and make it of Shutter wonā€™t freak out if you put other stuff besides images in the batch image folders. That being said, I would be careful.

2 Likes

@RapidBase

Iā€™ve been playing around with some opensource file managers today, and Iā€™ve found one that is a single PHP file upload, so it can be added to RW using a HTML Code Page type, or if you want to can FTP it into the batch folder manually.

It supports hashed passwords (I think thatā€™s the term!) and is really easy to configure.

As mentioned, you can if you wish add it (manually or via RW) to the batch folder; in which case give the folder name of ā€œbatchā€. Or you can upload it to itā€™s own unique folder (filemanager, etc.) then in the settings give it the path to the batch folder. Once thatā€™s done, the only folder the user can add and delete content from is the batch folder. Personally Iā€™d prefer the ā€œadding straight to the batch folderā€ (itā€™s just a single index.php file) option, but horses for courses.

You can restrict file sizes, file types and ever setup multiple users.

Looking at Github it seems well maintained having had security updates applied last month. But obviously, it comes with some huge caveats: 1. Itā€™s opensource. 2. I really donā€™t know what Iā€™m doing here. And 3. It might be a horrible insecure mess.

So far though, for me in testing itā€™s working really well. Itā€™s no Repository, but itā€™s a free workaround.

Iā€™m going to do some more testing on it, then, if Iā€™m happy with it, Iā€™m going to add a Shutter page to my next Foundry template and also include this as a HTML Code Page, that users just need to edit a bit, then boom, itā€™s all good.

Iā€™ll keep you posted.

EDIT: Hereā€™s the demo site Iā€™m working on. Obviously you canā€™t get into the filemanager, but you get the idea.

https://ci-clientservices.com/clientdev/shutter/

Once logged in this is what the file manager interface looks like.

Shutter is the folder for the images and the thumbnail folder. G3 is for something else Iā€™m working on at the same time, not related.

1 Like

That looks great, Steve. Thanks for all your research! And yes, adding this shutter solution to your next Foundry template would indeed be a great ideaā€¦ :slight_smile:

1 Like

TFM is lovely. I use it with some older plesk installations, where the build in filemanager is a nightmare (and plesk canā€™t be updated)