alt

requiring ^1 doesn't work, but requiring ^1.0 does

heggsta

@thats4shaw it (surprisingly) hasn't actually been too different from an SS2->3 or SS3->4

👍 (2)
max

Haven't had a chance to look at this issue yet.

max

Off the top of my head, I think folders won't be created unless there's a file in them that needs to be publish.

heggsta

As it relates to a migration, the folders may already have been created though

max

It looks like we have done something to disable versioning on Folders .. e.g. you can't publish/unpublish folders.

max

I wasn't there when this got set up, so I can't say why exactly.

max

Although, I could image that dealing with a scenario where you had an unpublished file inside a published folder inside an unpublished folder would be nightmarish.

max

Just looking at your StageFoldersLiveTask.php script.

max

Had your folders been sync in your DB before you upgraded to SS4?

max

The migration script only looks at know files. So if you have a folder/file in you assets that the CMS doesn't know about, the migration script won't discover them.

heggsta

Ooops, sorry, I didn't notice your replies... yes, the Folder records were already in the DB and file system

wmk

@heggsta are you using legacy filesystem? After running FileMigrationTask, the old folders and files should not be anymore in the file system with the new file system abstraction IIRC

heggsta

@wmk nope, not using legacy filesystem... and I am using the default FlysystemAssetStore

wmk

ah, the old "Uploads" folder remained, but all files were moved to "abcd1234" subfolders folders. Sorry. I'll check my converted project's database if folders are in live table

heggsta

the main reason why this was an issue for me is the system I migrated had over 2000 folders... going into the CMS and just Saveing folders to trigger Folder::onBeforeWrite() wasn't an option 🙂

wmk

yup, "Uploads" was recreated locally twice, cause the old folders (Uploads and Uploads/products) are not in live table

wmk

as a workaround you can write a buildtask that loops through all folders and publishes them for you. But I'd consider this a bug

heggsta

I did that already (linked to my task in the Github issue)... it worked fine for me, but would need some polish to be something for all to use

wmk

thanks for pointing me to a possible bug and/or data inconsistency

heggsta

no probs... I have this one too! https://github.com/silverstripe/silverstripe-assets/issues/216

Show 1 attachment(s)
gheggie

The task creates a new file if it was renamed during the name generation process, and leaves a copy of the original file in the filesystem (at the same hash directory location as the new file).

It seems like in this case the original is essentially an orphan file; if the "new" file is moved to the protected location with protectFile() the original is left behind and remains publicly accessible.

Hide attachment content
😳 (1)
heggsta

@max looking at the github issues for silverstripe-assets, it seems like #215 and #216 have just been ignored... is there anything I should have done when I raised them so they might be looked at and given some tags?


Show less replies
guttmann

had a page that relied on a specific Folder being available and it hadn't been published after running MigrateFileTask

heggsta

I should find a reference which I saw somewhere, probably a code comment, which basically said always make a Folder 'Live' (might be in Folder::onAfterWrite() or something)

heggsta

Folders are subclasses of Files, which are versioned, so...?