Drupal 8 has only 4 critical issues before getting released out of beta! Fingers crossed for a release this week!
The major issues that remain are:
- Fix the 'target_bundle' field setting - 'target_bundles' are not validated when entity_reference is enabled
- Prevent users from editing a content type's machine name once it has been set
- Document that certain (non-"href") attribute values in t() and SafeMarkup::format() are not supported and may be insecure
- hook_tokens() $sanitize option incompatible with Html sanitisation requirements
Taking into account the non-"href" attribute values and the SafeMarkup issues that have already been reviewed by the community, really that only leaves us with three issues. We are SO close, my friends!
At Freelock, we have already been working on some of our internal Drupal 8 sites and prepping them as great platforms for our clients. But, as many with sites, those sites have to work with our clients' day-to-day operations, which we call DevOps.
Being extremely involved with our clients, and as a project manager playing in Drupal CMS, I am always excited to hear about the new developments in our clients' operations and their complimentary technology. So many times I have seen clients who are set on WordPress or another SAAS, just then to be blown away by the capabilities of Drupal.
At Freelock, we still understand and advocate why a certain client should move over to a different CMS. Many times I have thought: You need a brochure site? WP is the CMS for you! We work with non-profits that need control/reporting of their donation systems, or clients who own county/national/international-wide websites that need full control over their systems. In these respects, they want something that they OWN, that they can TRUST, and a platform that is truly a powerful CMS. The security and dev community are always the reliable with Drupal, not to mention it's a fantastic framework that has taken years to develop.... Drupal is my top recommendation.
I can speak for me and all of our developers at Freelock, we are excited! We are so close to blasting open the dev world and expanding on the capabilities as a community. Countdown to D8! #2015PNWDrupalSummit
Industry
RC1 release date announced
The RC1 release date was announced at Drupalcon. Baring any showstoppers, it will be Wed 7th Oct.
8.0.0 will follow some time after that. It will be the first or third Wednesday of the month, and there will be 3 weeks notice given. That means the earliest possible date is 4th November. My money is on 2nd December.
After RC1 it should be safe and easy to upgrade between minor versions, so you should be safe to start developing against it. The biggest problem is likely to be lack of contrib support.
Just to piggyback on what
Just to piggyback on what ianthomas_uk said, there was a 5-6 week cycle through RCs for Drupal 7. A "Christmas gift" release for 8.0.0 would be awesome.
Start developing helper
Start developing helper modules again and yet again and then after all set up release a new Drupal. And then start over again and again.
A major issue here that is not given attention is that D8 is 3x bigger in code and 2x - 3x slower than D7.
Wow, Someone is skeptical ;-)
Wow, Someone is skeptical ;-) Regarding performance, you should check out: http://buytaert.net/making-drupal-8-fly Regarding code size, what you're not paying attention to is how much you can build with Drupal 8 with just core, and no contributed modules. With wysiwyg, responsive themes, views, media management and more baked into core, D8 needs far fewer contrib modules. By the time you add in contrib modules you need just to make a Drupal 7 site a nice, usable admin experience as well as modern, there's no way D8 is 3x as big. I just did a line count on a new D8 site, and compared to a relatively bare D7 site with all our stock modules. D8 had ~1.4 million lines of code. Our D7 site runs more like 2.2 million lines. I think beyond the caching wins that Dries cites in his D8 performance blog post, is simply the amount of RAM consumed by a single D7 request. In D7 (and previous), every single enabled module on the site gets loaded for just about every request (other than when the page is cached, which is not an option for logged in users). In D8, only code directly in the execution gets loaded -- which means I think we'll see it run on far more spartan web hosting environments than D7. And then there's the whole object-oriented discussion, which we think will do away with the "developing helper modules again and yet again" thing -- D8 is looking far easier to customize in tiny, tiny ways without having to do a huge amount of re-tooling. In short, D8 looks like a huge improvement, with wins in every category, and I can't wait to start using it everywhere.
@John
@John
Thanks very much for taking time to reply to my critique. In fact, D8 provides much functinality in core in contrast to D7. I think I should start building on it and simply start adjusting the mindset :) since sooner or later I will move to it.
Add new comment