Question: I’ve got the basics of a very large SS3 site up and running in SS4. Only some of the page classes are operational but I’m adding a section at a time back in.
Obviously the SS3 website is still running and the database and assets are evolving while the SS4 version stands still so I’ve been experimenting with bringing in the old SS3 database and assets into the SS4 version over and over.
I’ve got SQL scripts that do the ClassName changes in SiteTree for all of the pages. And I’ve written a little order of /dev/build things to do to bring in updated data quite easily.
I’ve been experimenting with the Assets MigrateFileTask with both (legacy_filenames: true and false) and I honestly prefer to keep it simple and keep legacy filenames for now.
One of the problems I’m having with both options is that SilverStripe 4 is writing the resized (Fill, Crop, Scale Image Class Methods) files right next to the original Image files. This seems much more messy than the old “_resampled” directory from SS3. Is there a way to turn this back on in SS4?
I’ve also noticed that if you place a new file into the Assets directory without uploading it through the CMS Files section it never gets picked up by the Files section when you visit the directory. Has this “directory scan” function been removed from SS4? Is there a way to re-enable this? That was super handy in SS3.
All SS4 NOOB questions I hope.
I’ve obviously been searching for all the class renaming that’s happened and seen the GitHub discussions about some of them. I didn’t find answers to the above observations I’ve had from my experiences with SS4 so far.
SS4 is quite robust and the error reporting is way better. The only error reporting that’s still rubbish is when you finally get the CMS to accept all the changes and upgrades to a Class are right and it then throws a “Internal Server Error” little notification to the top right and no error is reported anywhere. Sometimes forcing the URL to reload will then reveal a clue.
Otherwise it’s very robust and great that it doesn’t mess with the database when ¾ of your page classes are in a folder named “_wiating to be converted”. I’m super glad it doesn’t strip out data from the database when classes are missing.
This is in place because assets may or may not be published / accessible. Keeping them together with the original versions makes it all a bit more logical and tidy.
In SS4, the filesystem is now abstracted via Flysystem. This means that your files could live anywhere (local disk, AWS S3 bucket, FTP server, etc). This provides a lot more flexibility in terms of deployments, but obviously it removes the close-coupled nature of DB to filesystem that existed in SS3. It’s possible to run a script to import local files into the database, but if you want portable code in the “SS4” style, then all file operations really need to be done through the filesystem classes.
If you look at the network tab in your developer tools, you should be able to see the request and response that failed. If your site is in dev mode, the response should contain the full error message / trace (assuming it was something that the framework could catch). If it’s not there, then the server error logs would be the place to see what’s failing.
Thanks for the insightful replies. I really appreciate you taking time to reply.
The filesystem abstraction and file versioning support is great and I am glad it is available.
I guess what I’m saying is that if you were to tell SilverStripe 4 via a configuration setting that “I’m using the local filesystem” on this project (that’s the specification) then couldn’t it have some of the legacy functionality turned back on?
It’s all very good SilverStripe 4 is growing up and going all Enterprise but it’s leaving people with high quality SilverStripe 3 websites with an extra complex upgrade.
No Task script to clean up all the __resize files? Seems like an omission.
If it’s accessing the file system to write those __resize files then it should also have access to go and clean up the mess it made.
Do you know what the name of the script is to pick up assets into the DB that were added directly to the filesystem?
When I was reading the SS4 blogs the assets area was my biggest concern and I’m blown away they succeeded in abstracting it without absolutely breaking it.
I don’t believe there’s an existing script, but it’s relatively simple to do. If you have a local file, you can add it to the SS filesystem data with something like the following:
$file = Image::create();
$file->setFromLocalFile($localFile, $fileName);
$file->write();
//Publish the file if we can / want to
if (class_exists(Versioned::class)) {
$file->copyVersionToStage(Versioned::DRAFT, Versioned::LIVE);
}