You are not logged in.
Robert, not meaning to be pushy, but have you seen my earlier post?
Sure. Are you able to add an additional new image?
Yes, I am. It took the #id of 696, which is the next in line from what is displayed in the Images tab. However, I think #696 already existed in the folder :-(
In the images folder, I can see images up to #id 773 using Coda. The images open in preview too.
Precondition: The content of the
/images folder is not the source for the image tab’s list. The image tab’s list is built by reading all entries in the
txp_image database table.
So it looks like at one point in time the amount of “recorded” images (kept in the database) and the amount of image files in the folder started to diverge. Are you able to skim over the
txp_image table with phpMySQL or a similar tool and verify the content and amount of rows there?
Yes Robert, I figured out the same thing. I imported the DB over, but not quite sure what happened with the txp_image table. I will work on it tonight when back from work, and report back. Thanks for your help.
Downloaded and installed 4.0.6 on Nov., 18. (AFAIR)
This explains the symptom: We update development versions’ database structures by comparing some file modification dates to a date which is recorded when the site’s latest installation took place. By installing the older 4.0.6 “too late” the update procedure didn’t run. This would not happen in real life, neither with the final 4.0.7 release nor with an aged “real” 4.0.6 site from earlier this year.
Nothing to worry about.
Filenames should be preserved as much as possible now. It strips potentially harmful or illegal characters, but no longer attempts to create filenames that are free of url-encoded characters (the user can still do this himself by supplying an URL-friendly filename).
Filenames should be preserved as much as possible now.
Good move, thanks… except I used that handy
sanitizeForFile() function a few times in one of my upcoming plugins, and now the function’s been dropped… dammit!
No bother, I’ll just have to duplicate the regexes you’ve used inline in r3016 instead.
EDIT: unless you fancy putting those two lines inside a new
sanitizeForFile() function so we have an official mechanism for dumbing down filenames… :-)
Last edited by Bloke (2008-11-25 16:53:05)