Filename lengh issue
Server Software about: title: "REDACTED" theme: "danbooru2" url: "REDACTED"
versions: shimmie: "2.12.0-alpha" schema: 21 php: "8.2.28" db: "mysql 10.11.11-MariaDB-cll-lve" os: "Linux cp37-ga.privatesystems.net 4.18.0-513.9.1.lve.el8.x86_64 #1 SMP Mon Dec 4 15:01:22 UTC 2023 x86_64" server: "LiteSpeed"
extensions: core: ["admin","alias_editor","bbcode","comment","common_elements","download","et","ext_manager","four_oh_four","handle_pixel","help_pages","image","index","media","mime","post_lock","post_owner","post_source","post_tags","replace_file","setup","static_files","system","tag_list","tag_map","upgrade","upload","user","user_config","view"] extra: ["approval","auto_tagger","autocomplete","blocks","bulk_actions","danbooru_api","favorites","featured","forum","handle_mp3","handle_video","holiday","home","image_view_counter","notes","numeric_score","pm","pools","post_peek","private_image","random_image","random_list","regen_thumb","relationships","report_image","site_description","sitemap","source_history","speed_hax","statistics","tag_categories","tag_history","tag_tools","wiki"] handled_mimes: ["image/jpeg","image/gif","image/png","image/webp","image/avif","audio/mpeg","video/x-ms-asf","video/x-msvideo","video/x-flv","video/x-matroska","video/mp4","video/ogg","video/quicktime","video/webm"]
stats: images: 12054 comments: 118 users: 103
media: memory_limit: "8.0MB" disk_use: "1.7TB" disk_total: "2.0TB"
thumbnails: engine: "convert" quality: 75 width: 192 height: 192 scaling: 100 mime: "image/jpeg"
- Install method: GIT
Client Software (please complete the following information)
- Device: Desktop
- Browser: Firefox
Viewing images directly shows a nice URL (example: site.com/image/12352/12352.png) but the page title is the image ID followed by all the tags of the image (example: 12352 - tag1 tag2 tag3 tag4.png). When saving the file, the save image dialogue box suggests the very long image ID + tags title instead of something shorter, like 12352.png.
I do have an htaccess file that may be causing this:
rather than link to images/ha/hash and have an ugly filename,
# we link to images/hash/tags.ext; mod_rewrite splits things so
# that shimmie sees hash and the user sees tags.ext
RewriteRule ^_(images|thumbs)/([0-9a-f]{2})([0-9a-f]{30}).*$ data/$1/$2/$2$3 [L]
but even if I comment this out, it still shows the long page title and suggests the very long filename, along with the added bonus of all the thumbnails being broken. What's the default behavior of shimmie and is there currently a way to have it suggest something much shorter, like just the imageID.ext as the filename? Thanks
I am confused about the current setup --
-
site.com/image/12352/12352.png- suggests that niceurls are disabled (eg your main page is.../index.php?q=post/list) - Commenting out that line of .htaccess breaking thumbnails - suggests that niceurls are enabled (eg your main page is
.../post/list)
If niceurls work, then I'd generally recommend using them in all cases (pages, thumbnails, and full-size images)
If niceurls are working and enabled, but images are still being served at /image/<id>, then my guess is that there's an old config setting which is forcing that for some reason -- "Board Config -> Advanced -> Image URL format" (in the current version) or "Board Config -> Advanced -> image_ilink(in older versions) should control that. You would want to set it to something like_images/$hash/$id.$ext` in order to have images served the efficient way and with short filenames.
Also disclaimer this is going to be a very webserver-specific config issue, and I have zero experience using LiteSpeed; I'm just going by what I know from apache 😅
Niceurls are supposed to be enabled, the option is ticked on my setup page but I see what you're saying. If I disable sections of my htaccess page then the URLs go back to being 'not nice' even though the setting for them is ticked. Odd.
I checked and don't have the 'Image URL format' option but do have the 'image_ilink' and it is set to image/$id/$id.$ext. Setting is so that image has an _ at the beginning breaks thumbnails and images. I'm on 2.12 but I think my first install was 2.11, would that have been far enough back to have residual settings stuck somewhere?
The weird thing is the page URL does at least show correctly, it's just the page title that's really long, which I think is where the file is getting actually served from?
It sucks if this is going to be webserver-specific, as you can tell I'm not very experienced. Thanks for the insight so far.
If I were going to do a clean install would I only need the /data folder to retain all images and databases?
If I disable sections of my htaccess page then the URLs go back to being 'not nice'
Changing .htaccess shouldn't change the URLs that shimmie generates (ie, /index.php?q=page/name vs /page/name) -- if niceurls are disabled then .htaccess shouldn't come into play at all; and if nice urls are enabled, then disabling sections of .htaccess should result in 404s O_o
Setting is so that image has an _ at the beginning breaks thumbnails and images
Changing image_ilink shouldn't affect thumbnails at all, so something else is going on there o_O
would that have been far enough back to have residual settings stuck somewhere?
The default setting has been "empty" for a long time (where shimmie will come up with a sensible default on-the-fly based on whether niceurls are enabled or not)
The weird thing is the page URL does at least show correctly, it's just the page title that's really long, which I think is where the file is getting actually served from?
This long filename is specifically coming from the /image/<id>/... path (the niceurls-disabled image path) -- so if we could make the niceurls-enabled path work (/_images/<hash>/...) then that'd fix your issue
If I were going to do a clean install would I only need the /data folder to retain all images and databases?
/data has image files / thumbnail files / some settings (eg the database connection URL), then the rest is in the database (mysql in your case) -- though if you're thinking of a clean install, note that you're running PHP 8.2 which is now in "emergency fixes only" mode ( https://www.php.net/supported-versions.php ) where the latest code requires an "actively supported" version of PHP (ie, 8.4+)
So outstanding questions:
- has the code or config been changed?
-
.htaccessshould work when left as default -- either it works or gets ignored, but it should never need to be modified to have parts commented out -
image_ilink/image_tlinksettings should both work when empty -- if you want to change the filenames served to the user we can do that later, but let's try and get the basics working with default settings first
-
- do niceurls actually work?
- for pages (ie, manually visiting
http://mysite/post/list) - images (
http://mysite/_images/<hash>/123 - a b c.png) - thumbs (
http://mysite/_thumbs/<hash>/thumb.jpg)
- for pages (ie, manually visiting
- are niceurls enabled? (ie is shimmie generating links to
/post/list, or/index.php?q=post/list) - when you say "thumbnails are broken":
- what URL is shimmie generating? (right click the broken thumbnail - "copy image link" or similar)
- what happens when you visit that URL? (litespeed 404 page? shimmie 404 page? error message? something else?)
I went ahead and tested adding the _ in the ilink area again, thumbnails still work, but the main images fail to load. Trying to view image results in the error 'No handler could be found for the page '_image/12365/12365.jpg''
I checked with my server provider, I believe I found a way to update to 8.4. If I've got some kind of frankenstein mess, would the best option be to reinstall correctly using GIT and updated PHP to avoid any headaches in the future? Would a migration keep all comments, posts, notes, date/times, and other information intact? I appreciate all the help, but I'd hate to have you do all this legwork on a borked install. If yes, what would the steps be for migration and I can work on that instead.
My fulle htaccess is this: <IfModule LiteSpeed> IndexFiles index.php </IfModule>
<FilesMatch ".(sqlite|sdb|s3db|db)$"> <IfModule LiteSpeed> Order allow,deny Deny from all </IfModule> </FilesMatch>
RewriteEngine On RewriteBase /
rather than link to images/ha/hash and have an ugly filename,
# we link to images/hash/tags.ext; mod_rewrite splits things so
# that shimmie sees hash and the user sees tags.ext
RewriteRule ^_(images|thumbs)/([0-9a-f]{2})([0-9a-f]{30}).*$ data/$1/$2/$2$3 [L]
# any requests for files which don't physically exist should be handled by index.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?q=$1&%{QUERY_STRING} "[L,QSA]"
Rewrite for note creation, lower rewrite had incorrect redirect?
RewriteRule ^note/create_note$ index.php?q=note/create_note [L,QSA]
RewriteRule ^note/delete_note$ index.php?q=note/delete_note [L,QSA]
RewriteRule ^note/update_note$ index.php?q=note/update_note [L,QSA]
Rewrite the URL internally to index.php with q parameter
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,NE,B,QSA]
So actually nice URLs are not working? My htaccess file is just doing the work? Commenting out the rewrite rules does just go to the shimmie 404 page.
Are you able to answer any (or ideally all) of the questions at the end of my last comment? It'll be much easier to figure out a solution if I can see what the problem is, and right now there is critical information missing ^^;;
would the best option be to reinstall correctly using GIT and updated PHP to avoid any headaches in the future?
It looks like you're running a fairly old alpha build, which is generally a bad idea... but I'm pretty sure "being a few months old" isn't related to the current issue.
(To get rid of locally modified files and get in-sync with the latest code:
git fetch origin
git reset --hard origin/main
And to repeat -- the latest code only works with PHP 8.4 or newer)
Commenting out the rewrite rules does just go to the shimmie 404 page.
You don't need to comment anything out, you don't need to edit .htaccess at all, just leave it at the default 😅
I went ahead and tested adding the _ in the ilink area again, thumbnails still work, but the main images fail to load. Trying to view image results in the error 'No handler could be found for the page '_image/12365/12365.jpg''
What exactly are you putting into the image_ilink setting? This looks like a weird mixture of niceurl and uglyurl formats... but either way, leaving it as the default (empty) should work.
tl;dr: If you have niceurls configured correctly (ie, .htaccess is in its default state, nothing commented out), and niceurls are enabled in Board Config, then changing the filenames for images should be pretty easy. So let's figure out if niceurls are configured correctly and enabled in board config?
Thanks for your continuing help.
Currently image_ilink is set to "image/$id/$id.$ext" Directly viewing an image the URL looks like site.com/image/12365/12365.jpg If I blank out image_ilink the view images URL looks like site.com/_images/44ed289a0b617ce17416f9450f68f363/12365 - tag1 tag2 tag3.jpg
I had Nice URLs checked (and test passed) during both instances of this, as shown in my first screenshot.
According to CPanel, by my server provider, I was on PHP 8.2 but switched over and am now using PHP 8.4. I have been using Cpanel for github updates using a fork so I attempted an update after fully syncing, I haven't edited any files and am using the base install. After updating, the problem remains. Both are set to image/$id/$id.$ext but act in the same way as they did before, with the display URL showing site.com/image/12365/12365.jpg, but the title of the window (and subsequent suggested file name) being 12365 - tag1 tag2 tag3.jpg
My site info now shows: shimmie: 2.12.0-beta schema: 21 php: 8.4.7 db: 'mysql 10.11.11-MariaDB-cll-lve' os: 'Linux cp37-ga.privatesystems.net 4.18.0-513.9.1.lve.el8.x86_64 #1 SMP Mon Dec 4 15:01:22 UTC 2023 x86_64' server: LiteSpeed
Blanking the image and thumbnail URL format gives me the same behavior as above, where the URL turns into: site.com/_images/44ed289a0b617ce17416f9450f68f363/12365 - tag1 tag2 tag3.jpg
With the new update, my Nice URLs is still checked with the text (test passed - it is recommended to have them enabled)
Lastly, I've included a picture of the original HTAccess and mine, mine is slightly altered to work with Litespeed but should be doing the same thing. A few smaller issues cropped up but I won't bring those up right now.
Cool, with niceurls enabled and working, it should be possible to go to "board config -> advanced -> image URL format" and set that to _images/$hash/$id.$ext (in niceurl mode, only _images/$hash/ is important to Shimmie - everything after the slash is used as the image filename)
Yes, that worked! Thanks for your help, are you still using Kofi? Do you have the link to it if so?
Since updating I noticed two things, first is that when I click add note it seems that the note dialogue box is sometimes opened way off screen and isn't clickable. At first I thought nothing was happening when clicking Add Note, but if you click it again it gives you the message: Please save all notes before adding a new one. On one image I saw the add note dialogue box got opened really close to the top of the screen, which makes me think it is opening just offscreen.
The other is that generating thumbnails for video files doesn't work anymore. Clicking generate thumbnail doesn't show any errors and just loads a page where the thumbnail should go. I also checked data/temp/ffmpeg_thumb_test.png and it doesn't update.
https://ko-fi.com/shish2k
For the two other things I'd open separate github issues, as discussing unrelated things is likely to add confusion ^^;;
For the notes issue, it'd be good to know what other extensions you have installed (in particular which if any of the "zoom" variants)
For the video issue, it'd be good to enable one of the logging extensions (Database logging is probably simplest) and see if there are any encoder errors in the logs