Closed jsirish closed 4 years ago
jsirish
commented
4 years ago For ease of migrating sites running older versions of base-site, efforts will be made the keep the table names and field names the same. Ideally we could use a legacy.yml file to update class names and the data should update for the new system. Tasks can be created for data that does not migrate smoothly.
muskie9
commented
4 years ago The biggest thing is a clear upgrade path for sites running the current base site setup. I like the idea of the table names and we'll need to identify data that will not be moving to different tables (i.e. Company Config to Site Config).
If we can map some of that out in this thread we can quickly create tasks that will move everything from point A to point B.
I do like the flexibility this could bring with varying types of sites and having options to have a lighter installation if not everything is needed.
korthjp17
commented
4 years ago With the first glance at this, I think scaled uploads and obfuscator should be part of the base site. I think every site would need these.
Scaled uploads to help with the sizing of images and not having clients upload giant images in the CMS and obfuscator updates the email addresses anywhere in the site for better spam protection.
jsirish
commented
4 years ago @korthjp17 updated the lists above
jsirish
commented
4 years ago Data to migrate:
Company Config
Integration Config
Template Config
jsirish
commented
4 years ago Additional refactoring thoughts:
Page types
jsirish
commented
4 years ago closed via creation of dynamic/recipe-silverstripe-base-site
Overview
In an effort to streamline our base silverstripe sites, I propose to thin out the composer requirements for silverstripe-base-site, keeping the module "lighter" for small sites. Instead, we would create a new module recipe-silverstripe-base-site that would install the "kitchen sink" version of base-site.
note - this may work best as a new major version of base-site, or a new module that is not backwards compatible.
Requirements
base-site would keep the following requirements:
the recipe would have the following requirements:
requirements that would no longer apply to either module:
Additional Refactoring
The Dynamic config modules would be abandoned and reworked into the base-site module. In an effort to reduce database queries on page load, the company, integration and template configs will be applied to SiteConfig again. Field names will remain the same.
Company config will no longer require Locator for office location. Instead, create an Address dataobject that does not geocode. Company has_many Addresses, can mark one as primary so it can be referenced in the template.
Attempt to drop Core Tools requirement. Instead, pull out the few useful DataExtension classes and add to base-site (or a new module? foundation-helper).
Recommended config will be in the base-site readme, but will be copied to app/_config when the recipe is required.
Additional Thoughts
Timing-wise this would be a good time to refactor as the core theme is being updated for the new workflow. The new base site and core theme would be used for new sites moving forward.