Closed ghost closed 5 years ago
danharrin
commented
5 years ago I would also like to add that the Backend should be an SPA, or an SPA for each plugin/module. This has been extensively discussed on Slack, and everyone's main preference would be to use VueJS. Let's face it, jQuery is dying!
drmzio
commented
5 years ago As much as I would love a newer, better version of October, all this could take at least a year or longer unless we can find someone to work on this full-time. I would like to know what the original cofounders think about this.
LukeTowers
commented
5 years ago Show me da money 😝
I agree with some of your points, others are incorrect and could be included in October as it is right now but by far the biggest issue for this is monetary support to make it happen. I say monetary support and not just coding contributions because as the maintainers of the project we have to understand every single piece of it, so it doesn't actually make it any easier if we have random people building a "V2" for us because we still have to understand everything about it and modify it to better align with our vision.
If someone (or multiple someones) could front $100,000 then I think this could be doable. Otherwise I think it'd be better to keep up with the current approach of continually making October better.
ghost
commented
5 years ago @LukeTowers I'm just on the way to the bank to pull off the heist for you. 👍
To add an extra bit of info:
I was thinking of breaking this work up into modules and the admins can quality control every stage.
Most of the php code is pretty solid and good in October. The only updating of php would be with regards to the major laravel update which you opened a post about with the 5.9 / 6.0 LTS. I thought it made more sense for October version 1 to keep using 5.5 LTS and version two start using 6.0 LTS. Which helps to prevent people needing to update all their plugins, themes and website code in a rush.
The CSS and Javascript are the main issues plus all the vendor files.
A review of all the external vendor files by the admins would be great to see if we can get rid of a ton of dead code and switch to some newer vendor files. Also it would be nice to move all the vendor files in to the modules/backend/assets/vendor and modules/cms/assets/vendor and modules/system/assets/vendor folders only. As right now all the vendor files are all over the place and hard to keep track of updating them.
The first module, I was thinking and the hardest part is a basic re-write of the HTML, CSS and Javascript.
Basically having a simple setup of using flexbox for styling, use bootstrap 5, add critical css for the layout files and moving all the JS and CSS asset files into four section:
<head> JS sync - main build files[edit - see comment below]
Also take this example, you open a form page for a plugin October CMS will load every single javascript widget. You go to the CMS web page and again October CMS will load every single javascript widget - it's a complete waste of data to be loaded. It would be better to add some logic to load the only needed small javascript files. For example in the CMS web page we would only need to load the code editor javascript file and not the other widget javascript files.
<head> inline critical css
Bottom of web page - async all the rest of the CSS
Could also add some magic and start using variable fonts.
After that two main themes could be added a light and dark choice with an updated icon library e.g. Fontawesome v5.
The next stage would be to add vue.js and jQuery v4.0.0 (I believe jQuery may come in the next 6 months as they are already 50% done with that version). I really believe we should support both jQuery and vue as many people like both.
From there we could just add in the new widgets
And then all the new features
Testing each stage etc.
I'm up for working on this project as I think it's important to address some issues we are getting with not updating some things due to backwards compatibility issues.
frthjf
commented
5 years ago @ayumihamsaki I think this is an interesting discussion and it seems there are three main objectives you envision for an October v2:
1) Using a more modern/performant/secure technology stack that sacrifices backwards-compatibility on a regular bases (although clearly managed with semantic versioning) 2) Make October support more things out of the box (moving plugins into core, new widgets, CDNs, Dark mode, etc) 3) Explore entirely new directions like visual website builder, dev shops, crypto stuff etc.
As @LukeTowers pointed out, there are a number of things in there that could be achieved in the conventional v1 development process and it is really just limited by proper funding of the core team.
Now, I think 1-3) are all valuable and legitimate objectives, the question is whether these are objectives the majority of October founders and users have. I guess this is what is up for discussion here (not whether the objectives in itself are useful, since there are always use cases where a given objective makes sense like you've illustrated with your customer projects).
Personally, I find that none of the objectives 1-3) are something I envision for the October eco-system. One of key things I value about October is the predictability as a system. I develop a site once and I can let it run until it reaches it's natural end-of-life. I remember the Wordpress days where simple page edits and updates could jeopardise the integrety of the website. So I was happy finding the October system with a slightly outdated but lightweight, realiable and extensible core. It is always tempting to try and catch up with the latest web-technology developments but this tends to get quite pitiless very quickly. Even Bootstrap and jQuery 4 are legacy systems in some sense and if you want October to catch up with what the web has grown into over the years you might as well directly rewrite it as a headless NodeJS engine with SPA backend. It would all be extremely fast and secure but there's already a lot of systems out there that do that so why not go with them if you need the latest stack. Another aspect is that clients do not pay more because you use the latest technology but because the technology you choose brings relevant economic value to them. My guess is that reduced maintenance and cheap standard hosting is something that sells, while downloading a megabyte less when opening the backend goes widely unnoticed. This is not to say that we shouldn't try keeping stuff up to date as best as possible but only as long as it does not undermine October's outstanding reliability and the concept of no-version-2.
I think October made some very sensible design choices and there is lots of scope for improvement and value in the v1 platform. The much bigger issue I see in terms of long term plan and future is the lack of funding for the core team that is required to keep October thriving.
ghost
commented
5 years ago @frthjf interesting read.
To summarize my reason in a single paragraph the main reason for upgrading October to version two is as follows:
"Using old vendor packages and old versions of Lavarel LTS carries a huge risk or bugs and security issues! To address the issue of these vulnerabilities and bugs at some point you need to update to a certain level that can't continue backwards compatibility. A secondary factor is making sure the CMS has enough features that revival its competitors and address it's user's needs."
daftspunk
commented
5 years ago Some parts of this post are completely wrong, I don't see any bandages being applied like October is some wounded and dying platform. I see a maturing project that gets better with each release, it is stronger and more stable than ever and powers tens of thousands of websites, with thousands of happy developers. The backend is secure by default, it uses a throttle model.
The ideas October implements are the result of at least 10 years of planning and development. It's a hard pill to swallow for some people, not every website must be built with crazy modern tools.
You have permission to begin work and deliver on these ideas as a forked project. It took us 18 months just to build the core concepts and get the foundation layer right. Let us know when you are ready to demonstrate the first stage of improvement and we will review it based on merit. If the ideas and code are good, we will consider releasing it under the banner of version 2.
ghost
commented
5 years ago @daftspunk Ok no problem will do as you suggested, please see all my pull requests and work I have done for your repo over time as in good faith to this project:
daftspunk
commented
5 years ago Appreciate all your effort and hard work with this post and these PRs. Look forward to seeing your proposal!
edit: It would appear you have "ghosted". We've been trying to reach you about some of the issues you will face with this (check your email!). We have thought about the upgrade for a long time. The ideas embodied by October do not translate as easily as you might think. Good luck with your endeavours nonetheless.
ghost
commented
4 years ago I would not thrust PR proposed by a 👻 😄
drmzio
commented
4 years ago @ayumihamasaki2019 Are you on the October slack channel? Would love to share some ideas around for a new OctoberCMS.
Intro
For any project to be successful they need to think about the future and have a long term plan. October was first built many years ago and the internet has changed so much over that time. I have lost count in the number of API's I have learnt throughout that period of time.
Adding new technologies
Currently October CMS tries to fix issues like fixing a broken hose pipe by adding a bandage, this is only so good and not really a long-term solution.
With regards to October an example is Bootstrap. Currently it uses version 3 which is pretty poor and not fluid at all. Version 5 for example is a complete re-write and is fluid.
Big library changes
October CMS v2 can switch over to using the following etc:
and more...
jQuery v4.0.0
Shout out to my post over there: https://github.com/jquery/jquery/issues/4409
Bootstrap
Bootstrap 3 will move to end of life, and will no longer receive critical security updates.
Bootstrap 4 will move to Long Term Support after we release v4.4 and will no longer receive new features from then on. It will continue to receive bug fixes, security updates, and documentation updates.
Bootstrap 5 is under active development. You can follow our progress on GitHub here: https://github.com/twbs/bootstrap/projects/11
Breaking changes
I fully understand the admins not wanting to update October CMS to a new major version, due to breaking changes.
However, we have been talking at the company I work with the "what if" with regards to October CMS.
There are many new library versions that haven't been applied to October.
Ideas we have been talking about
If you load October in Chrome and open the dev-tools and see the network panel you will see huge data files being loaded, we are talking about 1.5Mb file sizes etc. this really is not a good idea with modern web design anymore.
Total re-write
We have even been talking about doing a complete re-write of the October CMS code, totally removing old sections of code and just rewriting things. For example, that the layout files currently we loaded a huge amount of data all sync and then have thousands of dom nodes all trying to process this huge amount of data.
Starting fresh and creating a modern app shell model, we can use a HTML5 template file using modern CSS like flexbox. We could just inline a few lines of critical css to create the basic app shell and make instant loading. Then start adding the important features of javascript via sync if needed and all the rest of the javascript and css files via async. Well over 90% of all javascript and css files right now could easily be moved to async. These 1.5Mb sizes files could be split up to take advantage of HTTP/2 and some code splitting could be added. Javascript has moved a long way since October was first creatied with ES6, Javascript modules and way too many things to mention.
Evergreen browser support only
All dead browsers should lose support. I'm talking about still supporting IE11. It's a dead browser, yet October still supports it and trying to support it actually hurts the new ever-green browsers!
A focus on new browsers such as:
etc. Should be enough, just look at github and you will see a message saying we only support modern browsers and it works for them.
Forking
I hate the idea of forking things! For example Bitcoin was created and then a bunch of scammers created a ton of hard forks. Most of those hard forks are dead projects!
Sure we could hard fork this project, but to me that is an insult to alex and daftspunk and the rest of the admins.
I think it would be much better to have two versions of October in this repo a version one (current - soon to be old version) and a version two (a new modern version).
Intergrating bug fixes
One issue would be how to deal with core bugs issues between the two versions?
Beta to stable
Version two could start with a beta tag and move to a stable tag when everything is pretty good and support for version one would make sense to be stopped.
Semantic versioning
Yes, version two would not be compatible with version one!
I really believe October should move to use Semantic versioning and this would help developers out with breaking changes. I know daftspunk doesn't want to move to a version two of October but hopefully this issue maybe useful.
Plugins
There are some plugins that have been created which are truly amazing and I think they should be added to version 2 core.
Plugins that add twig functions, plugins that minify, mime types, clearing cache etc.
etc.
People should vote for plugins they think should be added directly into the core in version two.
One example issue is October handling money and currency numbers. The author does a good job explaining the issue, found here: https://octobercms.com/plugin/initbiz-money
In this example this plugin issue should be added to the October core and some basic rules applied to them to standardise how October deals with money and currency numbers.
Old jQuery plugins
On the flip side there are many very old javascript jQuery plugins built into October right now. One example is the jQuery cookie plugin that is 10 years out of date. I worry about this type of plugin with security issues! Also their repo is dead.
There should be a review of all external javascript libraries to see which ones to keep and which ones to remove.
Again there are some that when updated will cause breaking changes, e.g. sweet alert v1 to v2. flot v1 to v3 etc.
API's
There are so many API's that should built into the core - way too many to mention.
HTTP Headers
Again same with HTTP headers, there should be several built directly into the core! e.g. referrer policy, timing policy, feature policy, content security policy etc.
Web standards
It would be nice to add other web standards projects into October CMS version two. One example would be the project https://html5boilerplate.com/
Adding their .HTaccess standard file for example directly into the core would actually harden October and prevent many security issues. Other projects that expand that are the Firewall v6 that many Wordpress security plugins add into WP's .HTaccess
Add missing HTML5 features
An example is a HTML5 range slider, currently October doesn't have anything for that:
There are many other HTML5 standard things we can add.
Widgets
There are so many cool widgets you could add to the core of October CMS version two. Take the charting for example currently there are three main types: bar, line and pie see here: https://octobercms.com/docs/ui/chart
Just look at modern charting libraries like D3: https://github.com/d3/d3/wiki/Gallery
You get a sense of how limited October CMS is right now.
Currently October CMS uses Raphaël (this is a dead project).
It would be much better to switch over to using D3.js and a newer library we can get more choice in our charts, here is a list of libraries out there using D3:
Charts
Another example is the code editor, right now we are using Ace editor. But many people would like to see code editors like Monaco being added.
We've already added grid layouts to October to add 4 column support, we've added a new color picker widget, see screenshot:
We've already added a dragbar feature
A dragbar and new pinbar
Lists and forms
Take lists for example, right now we just have a standard list view. At out company most of our custom plugins use cards instead of the text list. We like the idea of giving our clients a more visual result instead of a wall of text results, see example:
I know some people may not like the above example, but my point is that there should be a selection for users to choose from.
Blog and forum plugins
There are so many plugins that extend these two plugins, we should have a proper core feature of these two things!
Here's an example we have built and using in October CMS:
...and here's part of the meta section showing a preview of what it will look like in Google:
There's many more parts we have coded such as: Voice actions, search engine one boxes previews, google news meta-tags, meta title, meta description, meta keywords, meta robots, uri, author details, published or draft, primary image, dates such as created, modified and published, schema markup, facebook open graph, twitter cards, website details, social links, google maps, dmca info, hcard/vcard info, webmaster tools (6 different search engines), social apps e.g. facebook apps, speakable commands, google origin trials, special meta tags etc. all inside our blog plugin.
Above the Voice Action description field with character count, in the blog plugin. To learn more about Voice actions in search see here: https://support.google.com/websearch/answer/2940021?co=GENIE.Platform%3DAndroid&hl=en
Currently there are 5 major webmaster tools search engines and they could be built directly into the core, these are:
Plus other Chinese ones, too many to mention.
Our blog plugin is also split to be setup to support PWA and AMP-HTML at the same time. In our case our desktop websites are PWA and our mobile use AMP-HTML. So our plugins fully support both running at the same time.
Adding direct support to CDN and github
We've also created plugins that directly check the version numbers of external libraries hosted via CDN's to help the developer team keep track of any out of date libraries.
We've coded plugins that directly link your github plugins into October, to help with the work flow better.
We finished off someone's security plugin to create a checklist between development and production websites:
I forget the link to their repo, but we finished it off and added loads more tests to it.
Web Application Firewall (WAF)
Maybe adding a Web Application Firewall (WAF) to October CMS to add a layer 7 defense (in the OSI model), see below:
PCMS
Alot of CMS platforms are turning into progressive content management systems. Adding core features like Service workers, manifest files and many other features, see here: https://www.youtube.com/watch?v=s1WrBaAyzAI
Laravel 6 LTS
I think version two should start from Laravel 6 LTS and upwards.
Drag and drop
Make all the forms and lists be able to drag and drop all the fields and be able to save their layouts.
Dashboard
Total rewrite and use a modern drag and drop system and remove Isotope. Be able to import and export the layouts. Be able to download custom layouts from the marketplace just like Google Analytics does right now.
Frontend
Update the features, have the front-end editing support as standard.
JSON
Right now October has support for three things, javascript, css and rss for the plugin assets. We added support two years ago for JSON into our plugins and have created some very cool plugins.
Here's an example in action:
The
Group namefield is being populated by a JSON file via the:When a user makes a selection, October CMS then uses JSON data to fill in the
Purpose of the Groupfield to save time for the user to write the field. As you can see the api is very fast. The user can either edit the field or delete it and write their own. Either way we have made October CMS a bit more clever and trying to save the client time filling in the form details.Artisan
There are some nice plugins that extend it and they should be added into the core of version two.
Website builder feature
October CMS is good, but it's slow to build websites. There are other CMS that have a drag n drop feature to quickly build websites. This is aimed at people that can't code and makes website development quick and easy.
I know we have builder plugin, but that is aimed at more developers than non-techie clients.
I'm thinking more on the lines of things like weebly website builder.
Plus be able to drag n drop marketplace plugins on the frontend.
Core features
If there are features that are used by so many people, they should be added directly into the core of version two. I believe one example was the maintenance plugin allowing users to create an maintenance web page redirect and since then the plugin has been added to the core of October.
Likewise, all our websites are PWA and so the same thing could be done for offline web pages.
But I'm pretty much talking about everything, so any piece of software that you think should be added to the core, you can suggest below.
Dark and light modes
As standard be able to switch between a dark and light theme mode.
Featured plugins
We were thinking of changing the main menu and having a proper menu on the side which you can open and close to view websites with a large number of plugins. At the top were the top navigation menu is change that into a featured plugin list, where a user can select the most used plugins. Same like Windows 10 does with their apps. The more you use a plugin then it will pop-up in the featured list, based on your usage.
Let's say I use a plugin called Acme all the time but the location of that plugin is out of the screen view all the time because the author has given it the order of 500. So every time I need to use that plugin I have to scroll the top navigation to get it into view.
Because October v2 is clever it knows you use that plugin a lot and instead displays it in your featured list.
Speech
Add voice commands to October, it gets boring having to click a mouse to each section. Instead I would like to say "October, admin settings" October, cms page" etc. this may sound hard, but actually it's very easy with an API to add voice commands which uses Machine learning at the same time.
I'm talking about this: https://www.w3.org/standards/webofdevices/voice
Which has been around since 2013.
Help wizard
I need to check some doc's how to do something. I have to close October and go over to the website. It would be nice to have a help wizard, who remembers the days of clippy:
With machine learning these days, October could have something special.
Quick links
If you press the 'Tab' key a quick links sub-menu can appear to quick navigate the most common parts of the website. If you use keyboard controls, instead of pressing several keys to get to a location, you could select the option in the quick links list that drops down from the top.
Here's an example how Facebook does it:
Direct contact to staff
Sometimes things go wrong and the current method is kind of old and outdated.
Help I need October to fix something - "You can send an email to ..."
Instead, there can be a contact form in the settings section to file certain issues, such as:
All issues that are given the reply send us an email.
Add accessibility controls
You have a feature which turns on/off the accessibility controls in October, e.g.
Security
There are a few issues with the current setup with regards to October CMS, I will list a few of them:
However, 2FA is totally flawed and has major problems! This is why Google and others have created: U2F.
To learn more see here: https://www.troyhunt.com/beyond-passwords-2fa-u2f-and-google-advanced-protection/
October v2 should support out of the box: 2FA (not the txt messaging version as that can be hacked) and U2F.
I think two solutions can be:
a). All plugins on the marketplace need to be signed up to: https://snyk.io/
If you look at Rainlab User plugin it's registered with that company and helped find this issue: https://snyk.io/vuln/SNYK-PHP-RAINLABUSERPLUGIN-72142
b). Man in the middle attacks, there was a famous attack in The UK where 3000 websites were hacked at the same time. The cause was found to be a plugin all these websites were using. A hacker could hack one of the plugins and change the code in theory! The bad plugin code would be then running on any website using that plugin. A solution to this would be adding a HASH to all plugin versions just like Subresource Integrity (SRI). This way if a hacker changed the code, the HASH would not match and the website could then send a message to the October CMS admins to let them know about this bad plugin and take action asap.
As pointed out by another github issue: Add two-factor authentication to octobercms.com accounts
Vendor file security issues. An example is bootstrap, currently October is using V3. To get an idea of what I'm talking about you just need to see their release notes:
Running old vendor files is a big issue when it comes to security issues. Currently being held back due to backwards compatibility issues in October version 1.
Developer Shops
This idea is like a contact book, but built directly into the CMS. There are many wonderful developers in the October CMS community and it's not always easy trying to find their contact details on the internet.
In this concept idea, a company can list various things:
The reason to have this built directly into the CMS and not the October website would be, because then the company can communicate directly to the website they are working on with their clients. Allowing them to add Support ticket features etc.
This is pretty much the same kind of thing freelancer and upwork, but built directly into a section of the CMS. The idea is kind of based off Google Experts.
Multi-sites and hreflang
Better support and features for handling multi sites and websites with various language sections either built into sub-folder or sub-domain structures.
Crypto and decentralized
The biggest growth area in IT is related to crypto right now and there are many exciting and new things being created everyday now. October would be foolish to not be compatible with this industry.
Ideas
I'm sure many people could comment below and write down their wish list of features they would like to see in a version two of October CMS. Also it would be helpful to see a list of things people don't like with October that could be removed or fixed in version two.
Lastly, I would love to hear what the admins and authors think of creating a version two of October CMS that includes breaking changes and modern internet api's, libaries and frameworks etc.
October version 3
This can be in another 10 years time or less depending on how fast the internet has grown with new technologies. This gives users a 10-year support per version.
Discussion
I would love to hear what people think, if this is a no go. I'm also happy to close this issue.
Lastly,
This is a long-term project, which would be months to years long! All above suggestions are brain-storming ideas.
The point of October CMS version 2 is to use modern internet frameworks, libraries and api's this will result in breaking changes! But give the developers freedom to enhance the CMS into a positive direction!