Closed (won't fix)
Project:
Provision
Version:
6.x-1.1
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
21 Feb 2011 at 12:35 UTC
Updated:
23 Aug 2012 at 10:14 UTC
Jump to comment: Most recent file
Comments
Comment #1
anarcat commentedIf the http_port is missing, you can assume it's d()->server->default_port(), I believe. It's probably a bug that it's empty, but you can work around it.
That said, I do not understand what you're trying to do in that piece of code, I don't think you should be checking for ports, you mean to check ->ssl_enabled, no?
Comment #2
eugenmayer commentedcant check for ssl_enabled AFAIK as the object is not passed and it is not part of $data .. but thats an interesting idea
Comment #3
eugenmayer commentedanarcats advice was quiet useful, but it is not possible to do stuff like this with the current API. I attached a patch which extends the provision.api to pass the config object to the hook, which then makes it possible in that case e.g. to cann $config->ssl_enabled.
In addition i saw that the nginx hooks are not documented in provision.api.inc - i added them.
- We need to document nginx on http://community.aegirproject.org/node/70 and http://community.aegirproject.org/node/73
Comment #4
eugenmayer commentedtags
Comment #5
memtkmcc commentedThe patch from #3 has a few copy&paste typos for Nginx added stuff.
Comment #6
eugenmayer commentedfixed typos, added support for the settings hook.
Comment #7
memtkmcc commentedStill typo in the last
function drush_hook_provision_apache_server_config.Comment #8
eugenmayer commentedComment #9
anarcat commentedI think the solution here is to make sure the data you are looking for is part of the $data array in the configuration. If it's not in there, then it's not designed to be in the config file, period. that's the way the API works.
So here, you want to make sure that the port or ssl config is part of the data array.
Comment #10
crea commentedSubs
Comment #11
steven jones commentedSorry that this issue has sat here and stagnated for so long. Anarcat in #9 suggests that the better way to go about this is to pass the data into the config template using the existing data structures rather than passing the object in, so if anyone wants to re-open with which stuff isn't getting passed in correctly for them, and a rough idea of what how to pass it in then feel free. Otherwise, I'm marking as won't fix, as clearly no-one is really interested in fixing this.