Domain background enables site editors and content builders to change the background image or color of a domain on Domain Access-based websites. Requires use of Domain Configuration and Domain Settings sub-modules. This module extends the huge number of contributed modules that work with Domain Access.
Potential future upgrades might include Context integration, dynamic backgrounds, and support for inline CSS.
Though this is new to drupal.org, it's been under extensive testing and is currently in production-use @ http://calarts.edu
Project page: http://drupal.org/sandbox/ddiakopoulos/1203158
Comments
Comment #1
sreynen commentedMarking "needs review" so reviewers will see it.
Comment #2
ccardea commentedThe waiting time for a project application review is currently approaching six weeks. Please consider shortening your wait time by contributing to the code review process. All it takes is basic module writing skills, plus it is a great way to add to your knowledge of Drupal.Please visit http://groups.drupal.org/code-review for details on how to participate.
Comment #3
ddiakopoulos commentedPriority bump per http://drupal.org/node/539608
Comment #4
klausi* no README.txt
* Remove old CVS helpers ($Id) from all your files
* code style:
there should be no space before ')'
Comment #5
ddiakopoulos commentedThanks, Klausi. I just pushed the most recent update of the module to address your comments.
Comment #6
doitDave commentedAutomated review (Please keep in mind that this is primarily a high level check that does not replace but, after all, eases the review process. There is no guarantee that no other issues could show up in a more in-depth manual follow-up review.)
It appears you are working in the "master" branch in git. You should really be working in a version specific branch. The most direct documentation on this is Moving from a master branch to a version branch. For additional resources please see the documentation about release naming conventions and creating a branch in git.
Review of the master branch:
This automated report was generated with PAReview.sh, your friendly project application review script. Go and review some other project applications, so we can get back to yours sooner.
Comment #7
ddiakopoulos commentedShould be all fixed up based on coder output!
Comment #8
patrickd commentedIt appears you are still working in the "master" branch in git. You should really be working in a version specific branch. The most direct documentation on this is Moving from a master branch to a version branch. For additional resources please see the documentation about release naming conventions and creating a branch in git.
Review of the master branch:
This automated report was generated with PAReview.sh, your friendly project application review script. Go and review some other project applications, so we can get back to yours sooner.
Source: http://ventral.org/pareview - PAReview.sh online service
Comment #9
patrickd commentedSwitched back to needs review, so in-depth reviews won't be blocked by coding standart issues.
Comment #10
jthorson commented1. 'core' line in your .info file represents Drupal core, not your module.
2. For readability, please indent the options array in your $form item definitions.
Otherwise, it looks relatively clean ... could perhaps use another set of eyes on it. (Short and quick!)
Comment #11
ddiakopoulos commentedCreated a 6.x-1.0 branch and made jthorson's changes.
Comment #12
jthorson commentedAs per the release naming conventions, your branch should be named 6.x-1.x instead of 6.x-1.0 (which follows the 'tag' naming convention).
As branches represent a chain of commits over time, we use the '1.x' pattern when labelling them ... the code in a 'branch' changes with each commit added to the branch. A tag, however, is more specific, in that it represents the code at a specific point in time ... thus the '1.0' pattern.
Because Drupal's packaging scripts assume these branch/tag naming patterns, it becomes fairly important to understand the difference. :)
Comment #13
ddiakopoulos commentedAll fixed. Thanks.
Comment #14
atul.bhosale commentedManual review
as domain_background_settings_form() is used to configure background, the values of variables (domain_background_path, domain_background_color, domain_background_position, ...., domain-background-filename) get override by the last saved configuration as these sites use single shared database and in hook_init() only last generated CSS will get included as value domain-background-filename also get override in last saved configuration.
Feel free to change the status if this is incorrect.
Comment #15
ddiakopoulos commentedHi Atul,
Thank you for your comments. Domain Background is meant to be used with the Domain Settings module, which transparently handles the problem you describe, on a per-domain basis.
You are correct that a new file does get created every time. In a later update, I would hope to address this via ctools (specifically, ctools_css_store and related).
Comment #16
ddiakopoulos commentedBumping priority up since this has been in the queue since June 28th 2011
Comment #17
klausiSorry for the delay, but you have not listed any reviews of other project applications in your issue summary as strongly recommended in the application documentation.
There are still files other than README.txt in the master branch, make sure to remove them. See also step 5 in http://drupal.org/node/1127732
Review of the 6.x-1.x branch:
This automated report was generated with PAReview.sh, your friendly project application review script. You can also use the online version to check your project. Get a review bonus and we will come back to your application sooner.
manual review:
Comment #18
ddiakopoulos commentedComment #19
klausiThis application is not fixed? See http://drupal.org/node/532400
Please reopen if you still want to work on this application.