Updated: Comment #45
Problem/Motivation
We need to support Drupal 8
Proposed resolution
Especially the provision code needs to be adapted to work with e.g. CMI.
Remaining tasks
Site verify does not import packages info properly-- works- Platform verify does not import packages info properly (?)
- Similarly importing a drupal 8 site originally created using drush si breaks the site
TEST migrate tasks-- worksTEST clone tasks-- worksTEST delete tasks-- worksTEST backup/restore-- works- ?
User interface changes
API changes
Related Issues
#2008106: Prepare for REQUIRED sites/sites.php
#2104785: provision_drupal_system_map is using the old *.info construct.
#2104797: Load user-1 before drupal_flush_all_caches
#2104805: provision_drupal.drush.inc contains version specific code.
Original report by @tstoeckler
Currently it is impossible to install Drupal 8 sites with Provision.
Drush site-install supports D8 already, but there are no D8 equivalents of the D7 files in platform/drupal/.
Simply copying the *_7.inc files to *_8.inc files solves the problem. I would imagine simply removing the prefix would also work, but I didn't try that.
Comment | File | Size | Author |
---|---|---|---|
#66 | Packagesd8.jpg | 72 KB | omega8cc |
#33 | provision.code_.1194602-33.patch | 1.49 KB | helmo |
#28 | provision.code_.1194602-28.patch | 3.99 KB | helmo |
#26 | provision.code_.1194602-26.patch | 1.05 KB | clemens.tolboom |
#4 | provision-drupal-8.patch | 2 KB | tstoeckler |
Comments
Comment #1
Steven Jones CreditAttribution: Steven Jones commentedI think it would be safe to chase Drupal 8, in our 2.x branch..
Comment #2
tstoecklerI'd roll a patch if I could get some feedback on what the correct approach is. If I understand how these commands work correctly, then codewise this should be trivial (see op).
Comment #3
Steven Jones CreditAttribution: Steven Jones commentedBasically a copy of the _7.inc files to _8.inc should be enough at the moment.
Comment #4
tstoecklerHere we go.
Comment #5
tstoecklerNeeds review.
Comment #6
Steven Jones CreditAttribution: Steven Jones commentedI reckon we'll put this in a dev-branch for now, and we can keep and eye on it, and maybe even have Jenkins do that for us, and we can try to chase Drupal 8.
Comment #7
Steven Jones CreditAttribution: Steven Jones commentedAdded a dev-drupal-8 branch. Thanks!
Comment #8
Steven Jones CreditAttribution: Steven Jones commentedActually we need to do the Jenkins stuff I reckon.
Comment #9
realityloopPlatforms verify but sites fail using the above:
Comment #10
realityloopMore Debug output:
drush @hostmaster hosting-task 875 --debug
Comment #11
realityloopOk, so I had an old copy of drush in another location on my computer that was stopping this from working properly, I can confirm it's working properly once I updated links to the correct version of drush.
Comment #12
tstoecklerDue to the /core move (can't be bothered to find issue ATM), this is completely broken right now.
Comment #13
omega8cc CreditAttribution: omega8cc commentedSee #22336: Move all core Drupal files under a /core folder to improve usability and upgrades.
Comment #14
tstoecklerYup, Thanks :)
Comment #15
omega8cc CreditAttribution: omega8cc commentedWorking support for D8 is now committed in dev-drupal-8 branch: http://drupalcode.org/project/provision.git/shortlog/refs/heads/dev-drup...
It requires recent php-cli (I tested it with 5.3.10) plus heavily patched Drush 4, since it doesn't support Drupal 8 and we can't switch to Drush 5 yet.
You can find my working fork of Drush 4 head with required patches here: https://github.com/omega8cc/drush_4x
This site (see screenshots below) has been provisioned using everything above, so it works!
https://skitch.com/omega8cc/8cq9y/fullscreen-254
https://skitch.com/omega8cc/8cq9m/fullscreen-255
https://skitch.com/omega8cc/8cq9q/fullscreen-256
https://skitch.com/omega8cc/8cq92/fullscreen-257
Enjoy!
Comment #16
realityloopI've copied the three files from the Drupal 8 commit into provision-6.x-2.x installed as per the Drush 5 directions at: http://realityloop.com/blog/2012/07/03/nginx-mariadb-php-aegir-mac-os-x-...
I get the following when trying to create a Drupal 8 site:
Comment #17
Steven Jones CreditAttribution: Steven Jones commentedThis should get into 2.x
Comment #18
omega8cc CreditAttribution: omega8cc commentedAnother related patch - I didn't commit it to the dev-drupal-8 branch yet, which should be synced with 2.x anyway.
Comment #19
ergonlogicNote that Drush 5 just dropped support for Drupal 8. So, we'll probably have to move to (as-yet unreleased) Drush 6.x to fully support Drupal 8.
Comment #20
omega8cc CreditAttribution: omega8cc commentedSide note: even if Drush folks decided to drop D8 support in Drush 5, it still works in our Drush 4.6 + Aegir 2.x based Octopus fork - however recently D8 managed to break it again, so our latest working D8 platform is from September 15. At the same time Octopus still supports Drupal 5 - hence the use of Drush 4.6 in our Aegir 2.x fork.
Comment #21
helmo CreditAttribution: helmo commented"official" Drupal 8 support is probably not going to make it in 6.x-2.x.
I'm upping the version label for this and changing the title to make it clear this is about hosting Drupal 8 sites, not a D8 version of hostmaster.
Comment #22
davidrobinson_pw CreditAttribution: davidrobinson_pw commentedHas anyone had a more recent look at getting D8 into drupal.
The patches above are a good starting point but there are a lot more changes in Drupal 8 that need to be accommodated and Drupal 8 is still a bit of a moving goal post.
We did a quick bit of testing with the patches and the latest drush master to see what does work.
With a bit of digging the following drupal 8 differences need handling.
Some things can probably be resolved by getting the right code into provision/platform/drupal/X_8.inc but other things may need refactoring. Especially where an assumption that would have been valid for Drupal 5-7 no longer holds.
Comment #23
clemens.tolboomI planned to work on this issue but unfortunately this is hard as there are no recent patches in this issue :(
But he ... #2097363: Add site spins forever is my first step.
@helmo is helping me with this so hope to make some progress.
@davidrobinson_pw do you have a patch(set) through issues on d.o available?
Comment #24
helmo CreditAttribution: helmo commentedI've merged in all the changes from 6.x-2.x into the dev-drupal-8 branch.
And also done some cherry-picking from the omega8cc sandbox. There is is a lot though so there could be more :(
Comment #24.0
clemens.tolboomInserted template + comments from @davidrobinson_rw
Comment #25
clemens.tolboom@helmo tnx
Platform verify works and gets its packages.
For site add we need #2008106: Prepare for REQUIRED sites/sites.php which then fails at
which is probable fixable :)
Comment #26
clemens.tolboomHmmm .... sites.php does not contain anything ... so I'm not sure #2008106: Prepare for REQUIRED sites/sites.php is needed anymore.
I managed to add a site but not install. Doing a
drush @site site-install
made the site alive.Reset password fails with drupal_session_destroy_uid()
Comment #27
helmo CreditAttribution: helmo commentedThis feels like quessing... based on DRUSH_VERSION we should know what to call.
PS: your currently on Drush 7 (master branch)
Comment #28
helmo CreditAttribution: helmo commentedI've just committed a bunch of work from Clemens on the dev-drupal-8 branch ... this patch.
Not completely done... but we're getting there.
Comment #29
clemens.tolboomI've fixed a lot issues on the http://drupalcode.org/project/provision.git/shortlog/refs/heads/dev-drup... branch helped by helmo.
Thanks @omega8cc for the patches
Thanks @helmo for the immediate @ office support :)
Installing now works except for
This needs way more work + testing + tests.
Comment #29.0
clemens.tolboomMake list from remaining tasks.
Comment #30
clemens.tolboomThe installation fails due to
Calling hook drush_provision_drupal_post_provision_install
- calls our new platform/drupal/clear_8.inc
- calls drupal_flush_all_caches
which notified : WD DrupalKernel: Container cannot be written to disk. Drush solved this by #1801082-5: drupal_flush_all_caches() assumes a web request - "The service definition "router.builder" does not exist. "
is a real pain ... as it seems views are executed through RouterBuilder->rebuild().
Can we fix this by loading a users into global $user?
Comment #31
clemens.tolboomCore #2098421: Views are rendered when drupal_flush_all_caches through RouteBuilder->rebuild()
Comment #32
clemens.tolboomThe Core #2097327: Unecessary cache clear/router rebuild in views_menu() seems to fix this ... chasing head just by 1 day :p
Comment #33
helmo CreditAttribution: helmo commented@clemens.tolboom mentioned another issue to me:
during a site-install:
Use of undefined constant VERSION - assumed 'VERSION' provision_drupal.drush.inc:532
This seems to be the change notice: https://drupal.org/node/2082661
This patch generalizes it.. committing to dev-drupal-8 branch.
Comment #34
anarcat CreditAttribution: anarcat commentedwhat's the status here? is this complete / ready for testing? should we aim to merge this in the 2.0 release (see also #2023113: [meta] 2.0 release).
Comment #34.0
anarcat CreditAttribution: anarcat commentedUpdated issue summary.
Comment #35
helmo CreditAttribution: helmo commentedThis is not ready for #2023113: [meta] 2.0 release .. merging it later would be nice, but there is an element of 'chansing HEAD' involved ;)
So I expect that we merge this into 7.x-3.x and possibly keep this branch as a backport for those who need it.
Summary updated.
Speaking of issues... I saw these in the watchdog log when calling update.php from the browser... WSOD
It seems drupal wants write access to the settings.php ... needs investigation.
Comment #35.0
helmo CreditAttribution: helmo commentedtask update
Comment #36
clemens.tolboomThe current branch works for 6.x-2.x but I agree we should target 7.x-3.x in the end. For now @helmo and @clemens.tolboom try to make it work for 6.x-2.x as @clemens.tolboom need a Drupal 8 installation :p
Comment #37
clemens.tolboomI'm not sure whether I managed to enter the D8 site only through Aegir per #29. I guess now I did a
drush uli
I filed a new issue to make it easier to follow and/or fix issues.
#2104785: provision_drupal_system_map is using the old *.info construct.
#2104797: Load user-1 before drupal_flush_all_caches
#2104805: provision_drupal.drush.inc contains version specific code.
Comment #37.0
clemens.tolboomMake the dev branch more visible.
Comment #38
ergonlogicI've updated the sub-issues listed in #37 to target 7.x-3.x.
Comment #38.0
ergonlogicAdded more related items
Comment #39
phoang CreditAttribution: phoang commentedThere's one big issue is Drupal 8 require Drush 7. If we can get drush 7 works on Aegir 2 then I think we can host/create Drupal 8 platform on Aegir 2.
Comment #40
helmo CreditAttribution: helmo commented@phoang: Drush 7 "works" together with Aegir 2.x I use it on my dev Aegir. It is a moving target though.
The code here is still NOT complete and needs more work and testing.
I rebased and merged the dev-drupal-8 branch into 7.x-3.x. (After merging recent 6.x-2.x changes into provision 7.x-3.x)
This because I see Drupal 8 support as an essential requirement for Aegir 3.x. This should also make it safer to work on refactoring the code without merge conflicts.
Comment #41
clemens.tolboom@phoang please provide more info on
We had a few attempts installing D8 but never had a proper install. Always needed manual work. My last attempt was a '/me faces palms'
So I'm very curious about others experiences and steps taken.
I myself hope to give it another try during the upcoming sprint weekend
- https://groups.drupal.org/node/332998
- http://cheppers.com/blog/global-sprint-weekend-january-25-and-26-2014
- mine: http://drupal.nl/evenement/groningen-global-sprint-zaterdag-25-januari-2014
Comment #42
phoang CreditAttribution: phoang commented@helmo: Let's me try to install the Aegir 7.x-3.x branch to see if it works with a Drupal 8 platform.
@clemens.tolboom: I meant that as of the current Aegir 2.0 version is not support for Drush 7 and Drupal 8 platform. I had the some issues when trying to create a Drupal platform on Aegir 2.0
Comment #43
JakeWilund CreditAttribution: JakeWilund commentedI apologize if this is the wrong place to ask this question, but has current development mostly shifted to the 7.x-3.x branch at this point? I haven't upgraded to version 2.0 as I was more interested in waiting to run the d7 version. I know devs hate this question, and I'm not looking for anything specific, but where does the current 7.x branch stand and what's anyone's best guess as to when we might see a relatively stable build?
Comment #44
ergonlogic#43 is a little off-topic here, as there are other issues addressing the port to D7 and the state of various components. That said, yes development has moved to the 7.x-3.x branch. There isn't likely to be a direct 1.x to 3.x upgrade path, and since 1.x is essentially deprecated now that 2.0 is out, I suggest upgrading. A lack of support for semantic versioning on d.o will delay a stable release, but we hope to get an alpha release out in the next few weeks.
Comment #45
helmo CreditAttribution: helmo commented@JakeWilund: See #1261030: [meta] Roadmap: Aegir 3.x (D7 port) for more details about 7.x-3.x
Comment #46
ergonlogicWith a bit of tweaking to install_8.inc and the settings template, we're able to install D8 sites in the 7.x-3.x branch again. We still get an error when we try to retrieve the list of packages from the site though, since we're querying the 'system' table, that seems to no longer be there.
Comment #47
ergonlogicD8 sites will now install properly, though core throws an error. I've refactored the package management functions somewhat, though they need more work.
Comment #49
clemens.tolboomComment #51
realityloopI think we can safely close this because of #2306055: Platform verify fails for Drupal 8 under Aegir 3.x
Comment #52
Jon PughWoohoo! Way to go, team.
Comment #53
helmo CreditAttribution: helmo commented@realityloop: that might be a bit too quick. We still have a few remaining tasks in the issue summary.
Comment #54
realityloop@helmo: ah, sorry, is there a list anywhere of what still needs to be done?
Comment #55
helmo CreditAttribution: helmo commentedNot really a formal list, but the best place to start is the 'Remaining tasks' section in the summary of this issue. We can create child issues when there is work to be done, or something to discuss.
Comment #57
omega8cc CreditAttribution: omega8cc commentedComment #58
omega8cc CreditAttribution: omega8cc commentedComment #60
gboudrias CreditAttribution: gboudrias at Praxis Labs Coop commentedI don't know if this warrants another issue, but the Drush version 6.6.0 breaks Drupal 8 support, as documented in #2539946: drush defaulting to version 5.10.0 or 6.6.0 not dev-master (v.8)
Drush 6.6.0 does not support Drupal 8. See http://drupal.org/project/drush for more information
Comment #61
omega8cc CreditAttribution: omega8cc commentedThe problem is that Drush removed Drupal 8 support even in Drush 7, so we would need to depend on Drush 8 to be able to test/support Drupal 8 again. This comes with yet another problem, because Drush 8 (head) dropped support for PHP 5.3, so users should upgrade to PHP 5.5 or even 5.6, first. Which, of course, may affect some Drupal 6 contrib.
Comment #62
ergonlogicWe should revisit this, seeing as how Drupal 8 should be release at DC Barcelona. I've confirmed #2570389: Support Drush 7.x and #2570539: Support Drush 8.x both work, and we have tests on http://ci.aegirproject.org for both now. I'm going to leave the Drush8 test as-is, but copy it to a new "Drupal 8" test, so we can start to see where our Drupal 8 support really stands.
Comment #63
ergonlogicI added a stand-alone test for our Drupal8 support: http://ci.aegirproject.org/job/P_Aegir_Puppet_Module_functional_test_Aeg.... I'm only running our Drupal 8 tests here, since our Drupal 6/7 functionality is sufficiently covered by other tests. For now, this is installing Drush's "master" branch, until such time as a "8.x" one is created.
This test is currently failing, as expected. Here's an excerpt from the log, of the first error:
This appears to be related to the first couple outstanding items in the issue summary. That is, package management appears to be broken. So, when the site is imported into the front-end, it can't map to a profile.
The first warning happens a bit earlier:
Which appears to confirm that the issue is in
packages_8.inc
. However, I suspect that the issue originates in the platform verify, as we may not be pulling packages in there either. However, there's no indication of that in the logs here.Comment #64
omega8cc CreditAttribution: omega8cc commentedJust to share our surprise: For some reason, latest Drupal 8.0.0-beta15 (vanilla, no patches!) just works again with BOA-2.4.5, which still comes with Drush 7.0-rc2. This means that current BOA stable supports Drupal 6, 7 and 8, out of the box, with the same Drush version used. Pretty good D8 reloading!
BOA is now a bit weird beast, though, because we are running Hostmaster 6.x on top of Provision 7.x (with only minor tweaks), and we have avoided going beyond Drush 7.0-rc2, so we could still use it to test Drupal 8 support, which appeared broken over several betas, required custom patches etc.
Suddenly, Drupal 8.0.0-beta15 (vanilla) works again with no changes on our side.
Not sure if this may help here, but running Drush 7.0-rc2 allows to support Drupal 6, 7 and 8 (current beta15) -- of course PHP 5.5 is a must, but our own website runs on Pressflow 6 and PHP 5.6 for many months, with zero issues, so PHP version is no longer an issue (at least for latest Pressflow with some extra patches), unless someone runs some very ancient contrib.
Comment #65
omega8cc CreditAttribution: omega8cc commentedComment #66
omega8cc CreditAttribution: omega8cc commentedThis is how it works with Drush 7.0-rc2 on Provision 3.x with Hostmaster 2.x (and PHP 5.5.29)
Comment #67
omega8cc CreditAttribution: omega8cc commented"Release" & "Package type" is displayed properly on the site's packages list, while on the platform's packages list "Package type" looks fine, while "Release" column shows just "VERSION" word instead of, say, "8.0.0-beta15".
Comment #68
ergonlogicThe error that was causing our tests to fail was that the 'minimal' profile wasn't being found during platform verify. Subsequent tests install using that profile, and would thus fail. The issue was that we were searching for 'minimal.profile' which no longer exists. In
b8ef181be5c7
, I fixed this by searching for 'example.info.yml' instead. Tests are still failing, but later in the process.Comment #69
ergonlogicThis causes some odd behaviour, as we later include this file, to look for hook_profile_details(). I've reverted that commit, pending further investigation.
Comment #70
ChrisZZ CreditAttribution: ChrisZZ commentedI just managed to install drupal 8 RC1 platform on aegir after updating DRUSH to drush-8 with
composer global require drush/drush:dev-master
But now I struggle with initiating the site, it always stops.
This the first error
Drupal\Core\Installer\Exception\InstallerException Object ( [title:protected] => Error [message:protected] => Database name field is required. Database username field is required. [string:Exception:private] =>
In this is the second error
exception 'Drupal\Core\Config\StorageException' with message 'Write operation is not allowed.' in /var/aegir/platforms/drupal-8.0.0-rc1/core/lib/Drupal/Core/Config/InstallStorage.php:110 Stack trace:
Comment #71
omega8cc CreditAttribution: omega8cc commentedYou need to use Provision 3.x head to have all recent D8 related patches, required to fix problems introduced in Drupal 8 rc1. Then it will work: https://twitter.com/omega8cc/status/652433635358978048
Comment #72
ergonlogicInterestingly, I was able to install, backup, restore, clone and migrate a Drupal 8.0.0-rc1 site without any issues, simply upgrading to Drush master. I used the Standard profile, since we don't detect the Minimal profile (due to it not having a file called 'minimal.profile').
Of the "Remaining tasks" listed in the summary, (2) appears to mostly work, with the exception of the aforementioned profile detection issue. (3) on the other hand isn't something I ever thought we supported for prior versions. I didn't test it.
That all said, I think we're pretty close to being able to close this issue, and simply open issues to track the remaining rough edges. We will have to tackle how to support Drush 8 is a reasonable fashion (see: #2585275: Maintain Drush Debian packages). Also, I believe our tests need some re-work (see: #2581797: Fix up tests in preparation for D8)
Comment #73
ergonlogicSimply changing our D8 tests to use Standard profile, allowed out D8 tests to pass: http://ci.aegirproject.org/job/P_Aegir_Puppet_Module_functional_test_Aeg...
We can be reasonably confident about supporting Drupal 8 now. So I'm going to close this issue. Thank you all!
Comment #74
clemens.tolboomAwesome :)
Comment #75
gboudrias CreditAttribution: gboudrias at Praxis Labs Coop commentedWoohoo!
Comment #77
m.stenta@ChrisZZ: I am experiencing the same issue you reported in #70 (
exception 'Drupal\Core\Config\StorageException' with message 'Write operation is not allowed.'
).I created a new issue for it here: #2702963: D8 install fails with "Write operation is not allowed."
Did you ever figure out what was causing that? Please post to that issue if you have any insight.