Trying out Drupal 8

Last week was BADcamp and like many I opted to join in on getting some Drupal work done before and between sessions. Step one, looking through my dashboard to see what's in the backlog. Lots of issues and patches for the delete all module. Got that cleaned up, mostly. On to Drupal 8. Now, I had worked on a couple patches way earlier this year for D8, but things have changed.

Drupal 8 requires PHP 5.3 now, so first step, get a virtual machine going with PHP 5.3. Downloaded the new Ubuntu 12.04 LTS. Now, I like Ubuntu, but man, Unity is painful. Simply switching screens from OS X over to the VM would cause the Unity search to overlay the screen, not to mention that it was taking up 10% of my screen space with junk I'll never click. Fortunately, it wasn't too difficult to remove Unity and replace with gnome classic then install the rest of the needed LAMP stack components.

Now, finally with a VM meeting the requirements I could install Drupal 8. Create a new MySQL database, Git clone like normal (takes a while, we've gone from 3.42 MB to 4.5 MB), open the tarball and see there is still a default.settings.php (guess I haven't been paying attention enough, as I thought CMI was going to fully get rid of it in favor of yml configs) and copy it over to settings.php and make it writeable.

Ok, next step, run the installer. Hmm, well I had uninstalled Firefox, so guess I'll install Chrome. Except, as it turns out, it's apparently quite difficult to get a hold of a download URL for the google chrome debian package. Even using lynx led to failures for both chrome and chromium sites as they both required Javascript. Oh well, re-install Firefox. Maybe I should have tried installing Drupal using lynx, never know, may work.

Run installer. Can't install, need PHP GD libraries. Oh that's right, we need image manipulation tools just to run Drupal, cause that makes sense, right? Ok, sudo apt-get install php5-gd and we're good. Now to fill out the install form. Try root@localhost for e-mail, no dice, which I suppost conforms to the spec although I liked finding an old comment from Dries says we want to intentionally make that work. Ok, root@localhost.lan it is I guess. Next step.. Great! Wait, hmm. Click a link and get a 404. Drupal seems to have enabled clean URLs by default even though I hadn't set Apache up to support them. That's no good. Didn't the installer used to warn about that and turn Clean URLs off by default? Ok, click back button. Hmm, this doesn't work because I'm running into an #overlay link.

Ok, well I'll install drush and disable overlay. I mean, not totally necessary, but I know I'll be install drush at some point regardless, might as well now. Put drush in and run and then...

PHP Fatal error: Uncaught exception 'Exception' with message 'The configuration directory type active does not exist.' in /drupal/core/includes/bootstrap.inc:535

Well, shucks. Apparently, I need a newer version of Drush. Stable version is not gonna cut it. Ok. Dev version installed. New error:

Failed to write configuration file.

Ahh of course, /sites/default/files doesn't have the proper permissions. Didn't the installer used to warn me about that? Today it was silent. Alright, that done, "drush dis overlay --yes". Ok, click back. Alright path to config is /admin/config so let's try ?q=admin/config. No dice, I'm back to the front page. Ok, well guess I'll go set up Apache rewrite. I of course planned to eventually set it up anyways, but how about all those people who don't? Maybe something to do with this? I feel like there is an issue to file regarding the clean URLs snafu, but with the issue queue the way it is and deadlines looming, I don't want to inadvertently create a false bug report.

Ok sudo a2enmod then a trip to the clean urls handbook page to remember what I need to add to my site config (mind you this is all setup properly on my old Ubuntu install but I had to upgrade to a new install for this and thus don't have all these settings in place).

Alright, finally, back to the Drupal I know and love. Maybe I can start testing some patches now in hopes of helping out all those fine core developers and all the great work they do. But, I can't help but think, the 2013 release schedule for Drupal 8 is starting to feel a little rushed.

Comments

Some comments

Some comments

1) Clean url's are a requirement for drupal8 for several reasons. Maybe we can and should throw an error on installation. Not 100% sure it is possible. Can you open an issue for that? Anyway if I'm not mistaken the ?q stuff is replaced with mysite.com/index.php/admin/config for example. Not 100% sure about the path but it's somewhere in the issue queue. There is even a new contrib module that redirects ?q= paths to the correct url.

2) I think the GD stuff is only needed for the standard profile. Right? Tried minimal?

3) It's normal that drush isn't stable when core is moving that fast

4) We should show a nice message if config isn't writable. Did you try to install through the UI? If that works this is maybe a bug for drush? Anyway if you found the cause open an issue in the correct queue.

Seriously these issues can be fixed in like a week. Don't see why you think drupal 8 in the end of 2013 is going to be rushed because of this. There are way bigger problems we need to fix and conversions that need to happen than this. There is even a working upgrade path. And if the upgrade path doesn't work you should again open an issue for it ;)

Please don't take this as

Please don't take this as criticism, this is merely my experience. Personally, I'm happy to see all the progress and glad their are people smarter than me working hard on stuff. However, when you say "there are way bigger problems we need to fix", that's actually what I am getting at. We go into feature freeze next month, and we have big problems to fix, so it's highly unlikely these "smaller" problems will get dealt with.

I think there is an issue to file here, but with the deadline looming, it's intimidating to file an issue. I can put in the steps for reproduction, but what if it turns out it was environment specific and I've just wasted a core developer's time right before feature freeze? What if it turns out there is a change to make some desired behavior, but it's not a bug, then it's a feature, and then it's not going until D9 at the earliest at this point.

That's not to say it shouldn't be done, but the issue queue is a bit of a minefield (or rather *feels* like a minefield) at the moment.

A laugh in a tear...

Dear Coder in the Rye/Drupal Caulfield,
You're so right you funny man!
Would have taken you hours to go through all these frustrating steps. Thanks so much for pointing these out to us and "the Powers that be" in a way that's both entertaining and to the point.
There's a lot of goodies waiting for all of us in D8, but we need to clear and straighten the road to get there.
Rik

i trying to learn drupal.

i trying to learn drupal.
how to create a site like this http://www.eunited.com.my/
the slider image, displaying category on front page.

should i learn version 7 or wait 8 to come out first?

I'd suggest 7, at best, you

I'd suggest 7, at best, you are looking at a stable version of Drupal 8 with the contributed modules you need being available by about April 2014.

Use http://drupal.org/project/legacy_redirect

Hi,

For non-clean urls backwards compatibility you need to use:

http://drupal.org/project/legacy_redirect

Drupal just does not support non-clean URLs anymore as most other frameworks. This is coming from Symfony.

Best Wishes,

Fabian

And this is being released in

And this is being released in December? Good luck with that.

Drupal 8 roadmap

Nope.

Current release date is Aug. 2013: http://drupal.org/community-initiatives/drupal-core

Don't panic, they still have feature freeze, then code freeze ahead to finish it properly.

Nope.

No, Anonymous, it's being released September 2013. December is the cut-off date for new features.

index.php

If you do not want to enable mode_rewrite, you can access each page by prepending index.php to the path.
I.e.: if example.com/admin/config yields a 404, try example.com/index.php/admin/config

That said, that should definitely be documented somewhere!
(And hopefully Drupal 8 won't require php-gd anymore at release time (although Drupal has always required that, so that should be too big of a put-off))

Indeed, I didn't know about

Indeed, I didn't know about the new url structure, thank you!

glad I ran into this comment

glad I ran into this comment thread. I installed drupal 8 on a new Ubuntu install w/ external mySQL server. The install worked fine and all admin pages were accessible via overlay, but no settings or content were been written nor any errors recorded to logs. This was all solved by installing mod-rewrite

Didn't work for me with

Didn't work for me with postgresql and Apache2 on a Debian 7 VM. The install progress bar stopped at 73% (mostly, tried it about 10 times with various permutations of steps-- I should have taken notes with hindsight) for at least ten minutes with a message about installing the Help module. Reloading the page, it then quickly jumped to 80% or 90%, then finished. There were no pages (including the default page) in the site, and the admin pages were not accessible. The menus, links and Drupal icon appeared OK. I created the config file by copying the contents of the .htaccess file to the site file and merging it with the contents of 000-default, then removing 000-default. I guess it could be a redirect config error, but there was nothing in the error logs that indicated that with log level at Warn in Apache2, and as I said, the menus etc loaded OK. I didn't see any 404s in the network log in firebug.

That was with a standard install. Doing a minimal install completed without error or pause, but the site was then just a grey Drupal icon and a link to the root, nothing else.

Add new comment

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Comment using an existing account (Google, Twitter, etc.)