/core/admincp/album.php is miossing from 5.0.0 stable release

[jchlu]

I am testing 5.0.0 on a development machine prior to upgrading a live server and I'm trying to change the storage of attachments and album files to the file system, rather than the database.
The attachments works fine but every time I try and do the same with albums I get an error in AdminCP.
On further investigation, the links are pointing to a non-existing file - album.php.

[BirdOPrey5]

Where exactly in the Admin CP are you going to move albumbs?

[jchlu]

I just searched for the word "album" and get a list of links, one of which is "Album picture storage type"

[jchlu]

See attached grab for details.

[BirdOPrey5]

Thanks for the screenshot.

The bug here is that Album picture storage type should be removed from the Admin CP in VB5. Album pictures are just attachments in VB5 with a specific content type, there is no separate setting for them anymore.

Opened a bug report in the tracker- http://tracker.vbulletin.com/browse/VBV-8847

[jchlu]

Thanks Joe,
But I'm afraid I think I disagree - I have been testing v5 and I'm pretty sure that even since I changed the attachment storage to the filesystem, album uploads are writing as BLOB database entries.
I will confirm this for sure in a short while once I'm back at my development environment site but I'd appreciate a sanity check...

[jchlu]

OK,
I've investigated this further and apologies for doubting you Joe!
The album uploads are indeed being written to the file-system now, albeit in a different location to where I expected.
I created a folder named "vb_attachments" above the webroot for security and attachment images for user 4321 (as an example) were written to a subfolder named "4321" but I could see album images were not being appended to this directory.
Turns out the album images are written to a structure like this: vb_attachments/4/3/2/1/imagefile.jpg (in case anyone else is curious) so my testing the location by watching the user folder was what lead me to the wrong conclusion.
Thanks again.