Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
install system
Priority:
Major
Category:
Task
Assigned:
Issue tags:
Reporter:
Created:
10 Feb 2014 at 11:10 UTC
Updated:
29 Jul 2014 at 23:22 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
ianthomas_ukComment #2
sidharthapHere is the first patch file.
Comment #4
sidharthapAll this drupal_set_title has been addressed is different issues. In my D8 fresh instance i did not encounter drupal_set_title() in any of the files as mentioned.
Please close this ticket marking duplicate.
Thanks
Comment #5
ianthomas_uk@sidharthap: I think you must have your patch applied or something, I still see drupal_set_title in the repository. For example http://drupalcode.org/project/drupal.git/blob/f5ba64c9c190d7836a48660d1f...
Comment #6
sidharthapahh, i created the patch from fresh D8 copy. while applying the patch shows error.
error: patch failed: core/includes/batch.inc:107
error: core/includes/batch.inc: patch does not apply
is it related to my D8 instance or something else ?
Comment #7
chakrapani commentedHere is the re-roll from #2.
Comment #9
mfernea commentedI'm trying to see what's the problem here.
Comment #10
mfernea commentedHaving a look at the install or update processes the current patch doesn't really work. It uses the standard method of setting the title from https://drupal.org/node/2067859 or other similllar tickets, but here that doesn't work.
On the other hand Drupal installs just fine either by web interface or using drush.
Comment #11
vishalgala commentedComment #12
vishalgala commentedComment #13
sunThis requires a lot more adjustments. As I'm apparently becoming an install system expert, I'm going to take this over.
instalL_display_output(), Batch API, and update.inc to use proper render arrays.Comment #14
sun13: install.title_.13.patch queued for re-testing.
Comment #15
sun@dawehner had a cursory look at this and mentioned that the usage of the string translation service in the installer exceptions is a bit weird.
So I've changed that to follow existing practices in core.
Comment #16
dawehnerFirst note: No visual change while running tests in seven.
There aren't visual artefacts in the installer.
OT: This old strategy of calling drupal_render on anything just opens up new issues for all of the instances. this is pretty sad to be honest.
It would be kinda helpful to explain why we rethrow it in this case. This isn't obvious for me.
Do we have the form builder service available at that point of the installer?
Out of scope: This placeholder is quite odd.
We should fix @thows and use @throws directly.
Do we really need such changes here?
Should/Can we translate that bit?
It is great to have an explanation here.
Comment #17
sunFixed the actionable issues from @dawehner's review.
re 3) Yes,
FormBuilderis available at install time. The installer environment is not changed by this patch.re 6) It took me an entire hour to just find Seven's
install-page.html.twigtemplate override, so at minimum, I want to move the template into its./templatesdirectory here. — The fixes to the template itself are technically not really required here and only caused by further debugging, but they are certainly worth to do.re 7) Previous patches in here added t() around the strings in update.php, but I intentionally reverted those, because the special update.php environment is similarly complex as the installer environment, and I'm not very familiar with the update.php environment. This patch solely focuses on using #title instead of
drupal_set_title(). Wrapping those strings into t() should be considered in a dedicated separate issue.Comment #18
dawehnerYou probably can't argue against that, though at least from a theoretical standpoint the intersection between people knowing how the installer works and know how to proper write templates so that themes can leverage
them might be pretty small.
That is totally fine!
Thank you! This explains stuff.
Comment #19
wim leersThanks for reviewing this, dawehner — I started reviewing it also, but my knowledge of the installer is limited to say the least, so I'm glad you caught some of the "you shouldn't do X" things.
The patch itself looks entirely sane and clean to me. RTBC +1
Comment #20
webchickThis patch is at least 5-6 fixes in one. :( I don't see how I can commit this. Can we not have a fix just for the issue at hand?
Comment #21
sunIt's simply not that simple to convert legacy code in the installer, because the installer is still some massive plate of spaghetti.
This patch performs the desired change at hand. The necessary changes for this issue will coincidentally also allow us to proceed with modernizing the installer.
Aside from that, I simply don't have the energy to split every single installer spaghetti clean-up into a separate issue. Especially because there's hardly anyone who's able to and who will review those issues (in 2017, mayhaps). ~5% of the current code will remain once we're done. If we want to move forward, let's move forward. If we don't want to move forward, then well, fine, then state that clearly.
Comment #22
webchickMaybe catch or alexpott can take this one, then. I simply can't, I have no idea what's going on in this patch unless/until it's split up into digestible chunks.
Comment #23
catchLooking through the changes I can see this would be hard to split up - there's lots of places where $form['#title'] has to be used, but the form is being rendered to a string directly in the callback (which would ignore #title). Then once you do that you have to change some other things as well.
One question though:
There's a lot of effort gone into making these exception messages translatable, in fact that's a decent chunk of the patch, but:
1. We usually don't bother translating exceptions - in these cases they're equivalent to PHP error messages, just nicer versions of them.
2. Does that even work in practice?
Comment #24
sunYes, this works, as proven by attached screenshot. Testing it was easy by temporarily hacking
ExtensionDiscoveryand choosing a different language than English in the installer:However, the validation/error handling logic was not correct. Fixing that feels a little out of scope, but since you asked for a proof/test for this code, I guess we can fix it as well here.
Comment #25
dawehnerThere are a couple of instances which won't happen for normal users, one example is the following message:
We were unable to find any installation profiles. Installation profiles tell us what modules to enable and what schema to install in the database. A profile is necessary to continue with the installation process.Other examples though can easily happen for normal people using drupal, for which we should not require to learn the english language.
One example is the following message:
li>To start over, you must empty your existing database, delete your active configuration, and copy <em>default.settings.php</em> over <em>settings.php</em>.</li><li>To install to a different database, edit the appropriate <em>settings.php</em> file in the <em>sites</em> folderComment #26
sund.o issue comment conflict resolution--
Comment #27
catchOK cool that the translation works there. Still looks inconsistent with some exceptions getting passed the translation service and some a string run through t(), but that's even more out of scope for this issue. Moving back to RTBC.
Comment #28
catch26: install.title_.24.patch queued for re-testing.
Comment #30
sunMerged 8.x (cleanly)
Comment #31
catchCommitted/pushed to 8.x, thanks!
Comment #32
wim leersHurray! :)
Just one more now: #2209595: Remove drupal_set_title(), drupal_get_title() and associated tests.