Closed (fixed)
Project:
Drupal core
Version:
8.6.x-dev
Component:
Umami demo
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
29 Jan 2018 at 15:40 UTC
Updated:
23 Feb 2018 at 16:59 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
eli-tImproved language to reflect correct field name is Recipe Instruction rather than Body.
Comment #3
eli-tFirst attempt. I've actually put the instructions in .html files, as they are html, code editors will highlight/reformat correctly and it's not an issue if they are browsed directly.
Comment #4
eli-tSuggestion from @mark_conroy and @smaz to add a .htaccess file to stop the html files being served
Comment #5
markconroy commentedThis looks good to me and makes the CSV with things like alt tags for images waaaaay easier to read/edit. Marking as RTBC (this was also discussed on the weekly call today).
Comment #6
eli-tComment #7
larowlanany reason not to use
file_get_contentsinstead here, no need to use fread/fsize/fopen dance for such small filesWe need a test for the .htaccess protection.
See #2941488: Add a .htaccess file to core/profiles/demo_umami/modules/demo_umami_content/default_content/images to prevent direct downloading of images for sample test.
I don't think we need this, there are no php files in this folder right?
Comment #8
eli-tPatch to address everything in #7
In addition, the html files containing the recipes have had some newlines removed - these would be ignored when viewing them as html, but our import or filtering process was converting them in to html when displayed.
Comment #9
markconroy commentedI can't access images by going directly to their file.
I can't access html files by going directly to their file.
.htaccess for php is removed
Let's RTBC this.
Comment #10
gábor hojtsyWhat is the reason for some closing list items on its own line? Should they all be oneliners instead?
Comment #11
eli-tBefore this patch, the html for each recipe was contained in a single line on a CSV. To make it more readable I auto-formatted it in the HTML files using PHPStorm's Reformat Code option. The only manual change made was to remove the newlines that introduced, as mentioned in #8. I suspect where PHPStorm had introduced newlines, it moves the closing LF element to the following line.
Is there a standard we need to review .html files against?
Comment #12
kjay commentedHere's a patch that updates @eli-t's patch in #8 with fixes for @Gábor Hojtsy's feedback turning all the list items's into one liners.
Comment #13
kjay commentedSorry, interdiff for the previous comment.
Comment #14
markconroy commentedIt's a thing of beauty! Thanks @gabor for the suggestion.
Comment #15
larowlanWhilst reviewing this, I checked if we had test coverage for body fields already, which would verify that this feature worked.
But unfortunately, we don't.
We already have
\Drupal\Tests\demo_umami_content\Functional\UninstallDefaultContentTest::assertRecipesImportedIn which we do this
Can we add the following:
Then we're sure this doesn't get broken in the future.
Comment #16
eli-tSuggestion in #15 implemented.
Comment #18
eli-tField name was incorrect in the new test.
Comment #20
eli-t#18 is nonsense, it was missing the recipes.
This should be good. Apologies for the noise.
Comment #22
eli-tPrevious test failed because $node->processed was unavailable. I've changed this to $node->value and run the tests locally and it passes. As we are only testing that the content is loaded, and not how it processed, I think this is ok.
Comment #23
navneet0693 commentedThis should be good.
Instructions are in proper format. Here's an example:
Direct access to file results in forbidden response:
Comment #24
gábor hojtsyComment #25
gábor hojtsyThanks for taking care of all the bits raised, committed!
I would like to point out that the chosen sample text has some language issues: "the some of the" does not sound correct :) That said this is a pre-existing problem and can in fact be fixed easier once the files are on their own.
Comment #27
eli-tThanks Gábor! WRT the language in #25, that's been raised as a comment on https://www.drupal.org/project/drupal/issues/2940146#comment-12465501