Closed (fixed)
Project:
Spark
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Issue tags:
Reporter:
Created:
10 Aug 2012 at 19:47 UTC
Updated:
4 Jan 2014 at 02:24 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
webchickWell. I just totally don't understand this AT ALL.
The following code, when pasted into an execute PHP block on a real site works just fine.
But for some reason during install, it results in a node with only a title and not a body.
I'm sure I've done something very ridiculously stupid. :\
Comment #2
dman commentedJust a guess, this can happen if the content type you are creating ('page') hasn't yet been registered. No content type definition = no fields defined, no fields = no data gets saved to them. Now that 'body' is a field, (but title still isn't) there is that.
Order-of-operations during an install profile gets tricky like this, I remember wrestling with these things when trying to do an all-in-one preconfigured package before now.
if 'page' content type were actually provided by a module, then spark_demo could have that as a requirement, and dependency magic would make sure that 'page' exists before spark_demo is enabled.
For this reason, I've exported core 'page' and 'article' content types into really basic features in my own repo just so that my other features can list them as requirements.
... OTOH, it may not be this at all - just thought I'd drop a hint in passing because it looked very familiar.
[edit]
Yeah, looking at the code - spark_demo is listed as a requirement for spark : so will run its install before the spark install.
But it's the spark.install that creates a 'page' content type after that.
For this reason, my suggestion for a mini-module/feature that just creates the base content types would be my recommended solution.
Comment #3
webchickOh that is NUTS. Wow, thanks for that, I would never have figured that out.
Comment #4
dman commentedYeah, you can absolutely never replicate it in testing - the problem only ever occurs when bootstrapping an automated profile from scratch.
Though using the 'minimal' bootstrap profile can help identify a few missed or assumed dependencies.
Aside: I think that trying node_save on an unknown content type should really raise an exception, but hey, there's lots of soft spots like that.
Comment #5
webchickWell that's a grand idea. :) #1723108: Entity storage should throw an error when attempting to save an entity with a bundle that doesn't exist
Comment #6
webchickI was this close to creating a "standard_install" module to copy/paste the majority of the contents of standard_install() but after I threw up in my mouth, I declined and instead chose to cheat and put this in spark.install instead. I'm sure I'll live to regret that, but for now it unblocks alpha4.
http://drupalcode.org/project/spark.git/commitdiff/bdcc9c995a52d9c847247...
Thanks again for your help. I feel like we should capture this in the core queue somehow but I'm at a loss as to how we could even fix it; it's actually doing exactly what you want modules to do, which is run their dependent modules' code first.
Comment #7
webchickComment #8
mustanggb commentedI believe this is the commit intended to be referenced:
http://drupalcode.org/project/spark.git/commitdiff/6eed56fb1c672af540c1f...
Also to clarify this refers to the about us page creation and not the page content type, as I had originally understood it to mean. The page content type creation is already present in spark.install, which is what threw me.
Comment #9
webchickOops. :) Yes, thanks for the clarification.