-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CMS Research #81
CMS Research #81
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Danwhy thank you for summarising your initial research for these four options. 👍
Apologies that it has taken me longer than usual to review/comment on this PR. ⏳
My reason for not simply merging this immediately is that I wanted to give a detailed response as to why I feel that there was a "false premise" which lead to a "false conclusion" ... (which is 100% not your fault) ... we don't need a "fancy" CMS to CRUD the CS product/venue/review data, we need the simplicity and a specific schema which does not need a "drag-and-drop" interface to be managed because it will not change often. And when the Schema does change the "hard part" will be making it look good and easy to understand/interact with on the Frontend i.e. UX not the API/Backend.
Respectfully I disagree with the recommendation to use Contentful and I did not want to simply "reject" the PR without a decent explanation of why.
Contentful appears to be a good platform for a specific type of larger API/CMS project and for the people who need the "advanced" features it could be justifiable however on the basis that we would need to use their "Large Space" which is a $879 / month or $10,548 / year commitment which "blows the budget" for CS. 😞
I made my views on the CMS Spike/Research clear in: #5 (comment)
I feel that doing "CMS research" before having a crystal clear understanding of the types of content we need to schematise, capture, store and render is like selecting the engine for a vehicle before we know what the purpose of the vehicle is ... we could pick a V8 when what we need is an electric motor.
For anyone else interested in understanding these CMS and CMS-as-a-Service providers, we've have expanded on each of these in:
- Wagtail: Wagtail? dwyl/adoro#104
- Contentful: Contentful? dwyl/adoro#105
- Apostrophe: Apostrophe? dwyl/adoro#106
- Prismic: Prismic? dwyl/adoro#107
I am happy to merge a modified version of this PR, provided the "conlusion" is not a recommendation of a Closed Source service which "locks in" CS to paying $10k/year in "Rent". Please modify your conclusion to say: we are investigating content types further and are leaning towards defining an append-only-log schema using the Phoenix Frameword which is an Open Source "successor" to Ruby-on-Rails which will have a significantly lower lifetime "total cost of ownership" than a CMS-as-a-service provider and none of the "headache" of maintaining a Node.js-based CMS or Security issues of a PHP-based-system.
Thanks. ❤️
I take full responsibility for this one. @Danwhy had indeed also mentioned to me that this was the recommendation if we had to use an off-the-shelf product, rather than the recommendation full stop! Thanks again for the research @Danwhy, I found it a very enlightening set up for the conclusion to come 👍🏻 |
Closing this as no longer relevant. Ultimately we needed more flexibility than these could afford us 👍 |
Adds markdown file with the results of my research into various CMS options. Includes requirement checklist and a CMS recommendation.
ref: #5
@nelsonic It would be great to get your opinion on my recommendation, in case there's anything I may have missed that you're aware might pose a problem.