ASP Integration with Drupal?
A client wants to move an existing site to Drupal. The catch is that the existing site has two pages that are ASP. The ASP pages connect to a 3rd party hosted backoffice package and database. The clients current site is on a dedicated leased Win / IIS / Plesk Control Panel server. The Plesk package provides php 5.2 and MySQL 5 so I do not believe we will have any issues installing and running Drupal on the server. Does anyone know of any development, module, etc. that would allow us to integrate the ASP data into Drupal? Any other gotchas I should be looking for? Thank you all for the work you do and for the Drupal software. Ron D.
If it's only two pages, why don't you just rewrite them in PHP ? Beyond this, the question is what these ASP (raw ASP, or ASP.NET ?) data are: you might also want to modify the ASP pages so that they export their data to Drupal over SOAP: SOAP integration is integral to both ASP.NET and PHP5.2, and writing a SOAP server in PHP is trivial. ----- Original Message ----- From: "Ron Dorman" <rwd@simplydigtech.net> To: <development@drupal.org> Sent: Wednesday, August 15, 2007 8:00 PM Subject: [development] ASP Integration with Drupal?
A client wants to move an existing site to Drupal.
The catch is that the existing site has two pages that are ASP. The ASP pages connect to a 3rd party hosted backoffice package and database.
The clients current site is on a dedicated leased Win / IIS / Plesk Control Panel server. The Plesk package provides php 5.2 and MySQL 5 so I do not believe we will have any issues installing and running Drupal on the server.
Does anyone know of any development, module, etc. that would allow us to integrate the ASP data into Drupal?
Any other gotchas I should be looking for?
Thank you all for the work you do and for the Drupal software.
Ron D.
One thing to look at might be asp2php: http://asp2php.naken.cc/ if you're planning to rewrite a couple pages... On 8/15/07, FGM <fgm@osinet.fr> wrote:
If it's only two pages, why don't you just rewrite them in PHP ?
Beyond this, the question is what these ASP (raw ASP, or ASP.NET ?) data are: you might also want to modify the ASP pages so that they export their data to Drupal over SOAP: SOAP integration is integral to both ASP.NET and PHP5.2, and writing a SOAP server in PHP is trivial.
----- Original Message ----- From: "Ron Dorman" <rwd@simplydigtech.net> To: <development@drupal.org> Sent: Wednesday, August 15, 2007 8:00 PM Subject: [development] ASP Integration with Drupal?
A client wants to move an existing site to Drupal.
The catch is that the existing site has two pages that are ASP. The ASP pages connect to a 3rd party hosted backoffice package and database.
The clients current site is on a dedicated leased Win / IIS / Plesk Control Panel server. The Plesk package provides php 5.2 and MySQL 5 so I do not believe we will have any issues installing and running Drupal on the server.
Does anyone know of any development, module, etc. that would allow us to integrate the ASP data into Drupal?
Any other gotchas I should be looking for?
Thank you all for the work you do and for the Drupal software.
Ron D.
Eric Hole wrote:
One thing to look at might be asp2php: http://asp2php.naken.cc/ if you're planning to rewrite a couple pages... Interesting tool, Thank you Eric.
It will not fully resolve my current issue, but good to have such tools around. Ron D.
FGM wrote:
If it's only two pages, why don't you just rewrite them in PHP ?
I would love to to. I have built php that connected directly to MSSQL on a backoffice system. I have never before thought about having php connect to two different db servers in the same app. We would use the MySQL on the client server for Drupal, then need to connect to the 3rd party MSSQL for the small bits of data from the 3rd party inserted into the two pages. I have not seen that Drupal has the capability to support and connect to two different db's. Is there such capability I have not found yet?
Beyond this, the question is what these ASP (raw ASP, or ASP.NET ?) data are: you might also want to modify the ASP pages so that they export their data to Drupal over SOAP: SOAP integration is integral to both ASP.NET and PHP5.2, and writing a SOAP server in PHP is trivial.
The current pages are raw ASP. But again, one is the main/home page. If the sites is accessed with a sub-folder in the URL (www.example.com/sub1) the ASP (index.asp) page reads the backoffice server for a registered associate with an ID of the sub-folder name. If it finds such an associate, it inserts the associate name into the template for display throughout the site and sets a cookie with the associate ID in it. To run Drupal, we need index.php to be first in line preempting the index.asp page. I would have to modify Drupal to get the data from the 3rd party server before rendering the initial page.
----- Original Message ----- From: "Ron Dorman" <rwd@simplydigtech.net> To: <development@drupal.org> Sent: Wednesday, August 15, 2007 8:00 PM Subject: [development] ASP Integration with Drupal?
A client wants to move an existing site to Drupal.
The catch is that the existing site has two pages that are ASP. The ASP pages connect to a 3rd party hosted backoffice package and database.
The clients current site is on a dedicated leased Win / IIS / Plesk Control Panel server. The Plesk package provides php 5.2 and MySQL 5 so I do not believe we will have any issues installing and running Drupal on the server.
Does anyone know of any development, module, etc. that would allow us to integrate the ASP data into Drupal?
Any other gotchas I should be looking for?
Thank you all for the work you do and for the Drupal software.
Ron D.
-- Ron Dorman Simply Digital Technologies www.simplydigtech.net rwd@simplydigtech.net 817-503-7704 ofc 817-503-7719 fax 817-528-8947 cell
Ron Dorman wrote:
I would love to to. I have built php that connected directly to MSSQL on a backoffice system. I have never before thought about having php connect to two different db servers in the same app.
We would use the MySQL on the client server for Drupal, then need to connect to the 3rd party MSSQL for the small bits of data from the 3rd party inserted into the two pages.
I have not seen that Drupal has the capability to support and connect to two different db's. Is there such capability I have not found yet?
This is one of the cooler, not-so-well known drupal features. In settings.php you can define $db_url as an array $db_url['default'] = normal drupal string $db_url['backoffice'] = other mysql connect string then you use db_set_active( db_key ) to switch between them as needed.
Tao Starbow wrote:
This is one of the cooler, not-so-well known drupal features. In settings.php you can define $db_url as an array $db_url['default'] = normal drupal string $db_url['backoffice'] = other mysql connect string
then you use db_set_active( db_key ) to switch between them as needed.
Is this a standard core feature, enabled by default? I feel like saying "why wasn't I told about this before?" :) One of the big problems we have is that many developers working on a given codebase: this means the codebase is in subversion and people check it out to their own machines, work on it, check changes back in. Some developers develop on the same machine, because their desktops are WinXX and setting up LAMP stacks takes time. On this machine, whilst they can check out site-specific codebases to e.g. sites/developername-clientname-devel.example.com and hence develop in their own sandboxes, it's difficult to keep the site under revision and yet not have people be forced to share a database by settings.php . But with the above a high-priority module could switch quickly and cleanly between developers' own sandboxed databases: does that sound right? How would you sneak in before any of the other modules? Would the following at the end of settings.php be sufficient: db_set_active($_SERVER['HTTP_HOST']); // defaults to 'default' Or is that too hacky? Can you even call a function from within settings.php (notwithstanding the argument of "would you want to?") Somewhere among all this is functionality to make Drupal a good deal more "enterprise", for whatever that hackneyed term is worth. Transparently distributed development for large-scale, independent CMS teams on their clients' behalf. Cheers, J-P -- J-P Stacey +44 (0)1608 811870 http://torchbox.com
What we do with distributed development is to make an svs:ignore on the settings file, while putting a mysqldump synched with revisions. With scripts, so that one does a checkout, runs a script and is all set to go on the local installation. What you are saying would certainly be more elegant, so if you make progress, please comment! saludos, Victor Kane http://awebfactory.com.ar On 8/16/07, J-P Stacey <jp.stacey@torchbox.com> wrote:
One of the big problems we have is that many developers working on a given codebase: this means the codebase is in subversion and people check it out to their own machines, work on it, check changes back in.
Some developers develop on the same machine, because their desktops are WinXX and setting up LAMP stacks takes time. On this machine, whilst they can check out site-specific codebases to e.g. sites/developername-clientname-devel.example.com and hence develop in their own sandboxes, it's difficult to keep the site under revision and yet not have people be forced to share a database by settings.php .
But with the above a high-priority module could switch quickly and cleanly between developers' own sandboxed databases: does that sound right? How would you sneak in before any of the other modules? Would the following at the end of settings.php be sufficient:
db_set_active($_SERVER['HTTP_HOST']); // defaults to 'default'
Or is that too hacky? Can you even call a function from within settings.php (notwithstanding the argument of "would you want to?")
Somewhere among all this is functionality to make Drupal a good deal more "enterprise", for whatever that hackneyed term is worth. Transparently distributed development for large-scale, independent CMS teams on their clients' behalf.
Cheers, J-P -- J-P Stacey +44 (0)1608 811870 http://torchbox.com
Victor, would you please describe in fuller detail how you are providing distributed development? I don't quite understand what you are describing, but it does sound useful and interesting. Thanks, ..chrisxj On 8/16/07, Victor Kane <victorkane@gmail.com> wrote:
What we do with distributed development is to make an svs:ignore on the settings file, while putting a mysqldump synched with revisions. With scripts, so that one does a checkout, runs a script and is all set to go on the local installation.
If each developer has their own directory in the sites folder, don't they have their own settings.php? Aren't you just trying to move the switching into one giant settings.php file? On 16/08/07, J-P Stacey <jp.stacey@torchbox.com> wrote:
Tao Starbow wrote:
This is one of the cooler, not-so-well known drupal features. In settings.php you can define $db_url as an array $db_url['default'] = normal drupal string $db_url['backoffice'] = other mysql connect string
then you use db_set_active( db_key ) to switch between them as needed.
Is this a standard core feature, enabled by default? I feel like saying "why wasn't I told about this before?" :)
One of the big problems we have is that many developers working on a given codebase: this means the codebase is in subversion and people check it out to their own machines, work on it, check changes back in.
Some developers develop on the same machine, because their desktops are WinXX and setting up LAMP stacks takes time. On this machine, whilst they can check out site-specific codebases to e.g. sites/developername-clientname-devel.example.com and hence develop in their own sandboxes, it's difficult to keep the site under revision and yet not have people be forced to share a database by settings.php .
But with the above a high-priority module could switch quickly and cleanly between developers' own sandboxed databases: does that sound right? How would you sneak in before any of the other modules? Would the following at the end of settings.php be sufficient:
db_set_active($_SERVER['HTTP_HOST']); // defaults to 'default'
Or is that too hacky? Can you even call a function from within settings.php (notwithstanding the argument of "would you want to?")
Somewhere among all this is functionality to make Drupal a good deal more "enterprise", for whatever that hackneyed term is worth. Transparently distributed development for large-scale, independent CMS teams on their clients' behalf.
Cheers, J-P -- J-P Stacey +44 (0)1608 811870 http://torchbox.com
-- Regards Steven Jones
Earnie:
Perhaps something hacked into the projects/devel modules to switch the active DB on demand would be good? A developer could use his own DB for development and then switch the DB to production for a look and feel.
Yeah, this is a possibility. I'll have a look at those modules. We're already (as I explain below) using svn:ignore in our grand plan (although slightly differently from Victor's suggestion), so one possibility is for a developer to put a file on disk containing the name of his preferred DB, set an svn:ignore on the parent directory and switch database if that's present. That way the database can be safely wiped without losing that switch. Steven:
If each developer has their own directory in the sites folder, don't they have their own settings.php? Aren't you just trying to move the switching into one giant settings.php file?
Not quite: I didn't quite explain our plans for world domination fully! We still only have a small number of client sites in Drupal (3, well, 2.5 right now), but the plan we're still fleshing out goes as follows. We have a subversion repository containing "core" Drupal i.e. everything bar the contents of sites/ . It's actually not just core: there are tags for Drupal 5.1 and 5.2, and also tags for both of these with our always-used modules (CCK, image etc.) Maintaining this separate from Drupal CVS gives us control if we really, really want to do something different from standard out-of-the-box Drupal. The sites/ directory has an svn:ignore on it, so we can dump whatever we want under there and the "core" repository doesn't notice. Each client site has its own *separate* subversion repository, and this has its own settings.php file. This means that we can have e.g. three production servers, each with a single Drupal "core" instance, but then have e.g. ten client sites which we can roll out to any of those production servers and handle load, traffic spikes etc. If we know Client X is going to have a busy day, we can do DNS magic and redeploy the sites so that Client X is on a server on its own, and the other two servers share nine sites between them. Sites are completely plugin-able yet under subversion. In this situation, although each *site* has a settings.php, each developer is checking out the same settings.php from the repository per site. They don't want to be editing settings.php in case it gets folded back into the repository, deployed to live and breaks it. This means that, if two developers are working on the same development server rather than on their desktops, then even if they work on different physical files on the filesystem, subversion still gives them identical settings.php, and without extra effort they will end up sharing a database. Having some code that would switch database based on HTTP Host is ideal, really, as that's the main marker for Drupal to tell it which site it has to pretend to be ;) This switching seems perfectly natural, coming from an environment where local/live config switching is expected, and devel/test/prod config switching is generally desirable. Cheers, J-P ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Genius, I'd never thought about using SVN and drupal in that way. Indeed some database switching would be awesome. might have to have a closer look at all this. Let me know if you get anywhere yourself! On 17/08/07, jp.stacey@torchbox.com <jp.stacey@torchbox.com> wrote:
Earnie:
Perhaps something hacked into the projects/devel modules to switch the active DB on demand would be good? A developer could use his own DB for development and then switch the DB to production for a look and feel.
Yeah, this is a possibility. I'll have a look at those modules. We're already (as I explain below) using svn:ignore in our grand plan (although slightly differently from Victor's suggestion), so one possibility is for a developer to put a file on disk containing the name of his preferred DB, set an svn:ignore on the parent directory and switch database if that's present. That way the database can be safely wiped without losing that switch.
Steven:
If each developer has their own directory in the sites folder, don't they have their own settings.php? Aren't you just trying to move the switching into one giant settings.php file?
Not quite: I didn't quite explain our plans for world domination fully! We still only have a small number of client sites in Drupal (3, well, 2.5 right now), but the plan we're still fleshing out goes as follows.
We have a subversion repository containing "core" Drupal i.e. everything bar the contents of sites/ . It's actually not just core: there are tags for Drupal 5.1 and 5.2, and also tags for both of these with our always-used modules (CCK, image etc.) Maintaining this separate from Drupal CVS gives us control if we really, really want to do something different from standard out-of-the-box Drupal. The sites/ directory has an svn:ignore on it, so we can dump whatever we want under there and the "core" repository doesn't notice.
Each client site has its own *separate* subversion repository, and this has its own settings.php file. This means that we can have e.g. three production servers, each with a single Drupal "core" instance, but then have e.g. ten client sites which we can roll out to any of those production servers and handle load, traffic spikes etc. If we know Client X is going to have a busy day, we can do DNS magic and redeploy the sites so that Client X is on a server on its own, and the other two servers share nine sites between them. Sites are completely plugin-able yet under subversion.
In this situation, although each *site* has a settings.php, each developer is checking out the same settings.php from the repository per site. They don't want to be editing settings.php in case it gets folded back into the repository, deployed to live and breaks it. This means that, if two developers are working on the same development server rather than on their desktops, then even if they work on different physical files on the filesystem, subversion still gives them identical settings.php, and without extra effort they will end up sharing a database.
Having some code that would switch database based on HTTP Host is ideal, really, as that's the main marker for Drupal to tell it which site it has to pretend to be ;) This switching seems perfectly natural, coming from an environment where local/live config switching is expected, and devel/test/prod config switching is generally desirable.
Cheers, J-P
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
-- Regards Steven Jones
Quoting jp.stacey@torchbox.com:
In this situation, although each *site* has a settings.php, each developer is checking out the same settings.php from the repository per site. They don't want to be editing settings.php in case it gets folded back into the repository, deployed to live and breaks it. This means that, if two developers are working on the same development server rather than on their desktops, then even if they work on different physical files on the filesystem, subversion still gives them identical settings.php, and without extra effort they will end up sharing a database.
Yes. The install process now makes the settings.php file read only. This is the reason. Make sure this files mod settings is 444 for extra good measure that svn will not overwrite it on update.
Having some code that would switch database based on HTTP Host is ideal, really, as that's the main marker for Drupal to tell it which site it has to pretend to be ;) This switching seems perfectly natural, coming from an environment where local/live config switching is expected, and devel/test/prod config switching is generally desirable.
I hope and have assumed you're aware of the multi-sites features for version 5? sites/all/modules sites/all/themes URL http://www.example.com/dev/user1 sites/www.example.com.dev.user1/settings.php sites/www.example.com.dev.user1/modules sites/www.example.com.dev.user1/themes URL http://www.example.com/dev/user2 sites/www.example.com.dev.user2/settings.php sites/www.example.com.dev.user2/modules sites/www.example.com.dev.user2/themes URL http://www.example.com/test sites/www.example.com.test/settings.php sites/www.example.com.test/modules sites/www.example.com.test/themes URL http://www.example.com sites/www.example.com/settings.php sites/www.example.com/modules sites/www.example.com/themes It is recommended that modules and themes that affect all sites be placed in sites/all/modules and sites/all/themes. Then dev user 1 can place the modules she is working on in her local site while dev user 2 can place the themes he is working on in his local site. When test is ready, the modules and themes are placed in the test local site. Now to deploy I will bet you can guess what is next. Earnie
Hi Earnie,
I hope and have assumed you're aware of the multi-sites features for version 5?
Yes, but it doesn't really solve the problem if we have several copies of a client's site on the same server with each developer working on a copy: sites/jp.client.example.com sites/fred.client.example.com Because both are subversion'ed, both settings.php will be the same; both will therefore access the same database without some sort of hack, and Fred might find his development stymied by my db changes. If Fred changes his settings.php to point to the database db_drupal_client_fred, then he's in danger of checking that in and (a) me getting the same change when I grab any updates from the repository or (b) worse, that change hitting the live site, which immediately keels over. Everything ought to go through a test site, of course, but this becomes a potential point of failure if urgent work is needed and the test site is underused. Cheers, J-P -- J-P Stacey +44 (0)1608 811870 http://torchbox.com
On 8/17/07, J-P Stacey <jp.stacey@torchbox.com> wrote:
Hi Earnie,
I hope and have assumed you're aware of the multi-sites features for version 5?
Yes, but it doesn't really solve the problem if we have several copies of a client's site on the same server with each developer working on a copy:
sites/jp.client.example.com sites/fred.client.example.com
Because both are subversion'ed, both settings.php will be the same; both will therefore access the same database without some sort of hack, and Fred might find his development stymied by my db changes.
just svn:ignore settings.php But the insurmountable problem is the impossibility of merging configuration changes. Also, even content import/export is hardly straightforward (complex relationships with taxonomy)... If Fred changes his settings.php to point to the database
db_drupal_client_fred, then he's in danger of checking that in and (a) me getting the same change when I grab any updates from the repository or (b) worse, that change hitting the live site, which immediately keels over.
Everything ought to go through a test site, of course, but this becomes a potential point of failure if urgent work is needed and the test site is underused
The only solution is that someone (usually me where I am) has to serve as "head cook and bottlewasher" integrator in the test site. The plot also thickens when customer needs to get content up in parrallel with old version... Victor Kane http://awebfactory.com.ar .
Cheers, J-P -- J-P Stacey +44 (0)1608 811870 http://torchbox.com
Quoting Victor Kane <victorkane@gmail.com>:
Everything ought to go through a test site, of course, but this becomes a potential point of failure if urgent work is needed and the test site is underused
The only solution is that someone (usually me where I am) has to serve as "head cook and bottlewasher" integrator in the test site.
Scheduling testing is a large complication that should not be avoided just because a deadline is near or past. Testing must be planned in the schedule.
The plot also thickens when customer needs to get content up in parrallel with old version...
But manageable none the less. Earnie
Right, the test site exists in our case because we (try at least to) organize our development around a test driven approach. Which involves an iterative approach. The test site is there and is tested incrementally with several versions. Victor Kane http://awebfactory.com.ar On 8/17/07, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Victor Kane <victorkane@gmail.com>:
Everything ought to go through a test site, of course, but this becomes a potential point of failure if urgent work is needed and the test site is underused
The only solution is that someone (usually me where I am) has to serve as "head cook and bottlewasher" integrator in the test site.
Scheduling testing is a large complication that should not be avoided just because a deadline is near or past. Testing must be planned in the schedule.
The plot also thickens when customer needs to get content up in parrallel with old version...
But manageable none the less.
Earnie
Well since everyone else is sharing their dev environments, I figured I'd throw ours out there. And because I am physically incapable of doing so briefly :-), I decided to make a blog of it: http://www.garfieldtech.com/blog/drupal-dev-server Hope that's useful to someone, and feedback welcome. :-) --Larry Garfield On Fri, 17 Aug 2007 13:08:15 -0300, "Victor Kane" <victorkane@gmail.com> wrote:
Right, the test site exists in our case because we (try at least to) organize our development around a test driven approach.
Which involves an iterative approach. The test site is there and is tested incrementally with several versions.
Victor Kane http://awebfactory.com.ar
On 8/17/07, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Victor Kane <victorkane@gmail.com>:
Everything ought to go through a test site, of course, but this
becomes
a
potential point of failure if urgent work is needed and the test site is underused
The only solution is that someone (usually me where I am) has to serve as "head cook and bottlewasher" integrator in the test site.
Scheduling testing is a large complication that should not be avoided just because a deadline is near or past. Testing must be planned in the schedule.
The plot also thickens when customer needs to get content up in parrallel with old version...
But manageable none the less.
Earnie
Victor Kane wrote:
just svn:ignore settings.php
To me, that's a bit dangerous: the recent Drupal security advisory notice(s) affected settings.php, didn't they? So you'd have to check every live site's settings.php by hand if something like that happened again. Maybe the svn-enabled solution is to override in another file, bring it in as an include, and svn:ignore that other file: settings.php: $db_url = 'db_default_name'; include("settings_override.php"); // file not found: fails silently? svn:ignore'd settings_override.php $db_url = 'db_freds_own_database'; Be nice to have a native Drupal solution, though. And that's an extra file hit per request. Cheers, J-P
On 8/17/07, J-P Stacey <jp.stacey@torchbox.com> wrote:
Victor Kane wrote:
just svn:ignore settings.php
To me, that's a bit dangerous: the recent Drupal security advisory notice(s) affected settings.php, didn't they? So you'd have to check every live site's settings.php by hand if something like that happened again.
It is quite a bit less likely now since there is relatively little PHP code in settings.php now. -- Neil Drumm http://delocalizedham.com
Quoting J-P Stacey <jp.stacey@torchbox.com>:
Hi Earnie,
I hope and have assumed you're aware of the multi-sites features for version 5?
Yes, but it doesn't really solve the problem if we have several copies of a client's site on the same server with each developer working on a copy:
sites/jp.client.example.com sites/fred.client.example.com
Because both are subversion'ed, both settings.php will be the same; both will therefore access the same database without some sort of hack, and Fred might find his development stymied by my db changes.
As Victor pointed out you can set svn to ignore the settings.php file. Also setting it as read only prevents an accidental overwrite.
If Fred changes his settings.php to point to the database db_drupal_client_fred, then he's in danger of checking that in and (a) me getting the same change when I grab any updates from the repository or (b) worse, that change hitting the live site, which immediately keels over.
Maybe a change to settings.php is in order to where <?php if (file_exists('db.settings.php')) { include_once 'db.settings.php'; } ?> and db.settings.php is never stored in the VCS.
Everything ought to go through a test site, of course, but this becomes a potential point of failure if urgent work is needed and the test site is underused.
Urgent work usually requires urgent failures. :t I don't like sitting on 12 hour long calls hand holding the client while development fixes the issues that went untested for a release. Yes, my ``daytime'' job is application support. Earnie
Earnie Boyd wrote:
Maybe a change to settings.php is in order to where
<?php if (file_exists('db.settings.php')) { include_once 'db.settings.php'; } ?>
and db.settings.php is never stored in the VCS.
Yep. Sounds like that's the way to go. The file_exists would give me a safety net. Thanks for all your comments:
Yes, my ``daytime'' job is application support.
Especially you, Earnie. I don't envy you! Cheers, J-P
Quoting J-P Stacey <jp.stacey@torchbox.com>:
Somewhere among all this is functionality to make Drupal a good deal more "enterprise", for whatever that hackneyed term is worth. Transparently distributed development for large-scale, independent CMS teams on their clients' behalf.
Perhaps something hacked into the projects/devel modules to switch the active DB on demand would be good? A developer could use his own DB for development and then switch the DB to production for a look and feel. Earnie
J-P If you want developers to share code with the live site, then that should work. The database is not the only component here. There are modules and themes too. It is not a good idea to have developers share code that is actively in development with a live site. You want to give them write access to the sites/all/modules and sites/all/themes (and/or whereever else they have code they need to muck around with). This is not a good practice in general. Now, if you are talking testing/staging and live, where no code changes are done, then you have a point. On 8/16/07, J-P Stacey <jp.stacey@torchbox.com> wrote:
Tao Starbow wrote:
This is one of the cooler, not-so-well known drupal features. In settings.php you can define $db_url as an array $db_url['default'] = normal drupal string $db_url['backoffice'] = other mysql connect string
then you use db_set_active( db_key ) to switch between them as needed.
Is this a standard core feature, enabled by default? I feel like saying "why wasn't I told about this before?" :)
One of the big problems we have is that many developers working on a given codebase: this means the codebase is in subversion and people check it out to their own machines, work on it, check changes back in.
Some developers develop on the same machine, because their desktops are WinXX and setting up LAMP stacks takes time. On this machine, whilst they can check out site-specific codebases to e.g. sites/developername-clientname-devel.example.com and hence develop in their own sandboxes, it's difficult to keep the site under revision and yet not have people be forced to share a database by settings.php .
But with the above a high-priority module could switch quickly and cleanly between developers' own sandboxed databases: does that sound right? How would you sneak in before any of the other modules? Would the following at the end of settings.php be sufficient:
db_set_active($_SERVER['HTTP_HOST']); // defaults to 'default'
Or is that too hacky? Can you even call a function from within settings.php (notwithstanding the argument of "would you want to?")
Somewhere among all this is functionality to make Drupal a good deal more "enterprise", for whatever that hackneyed term is worth. Transparently distributed development for large-scale, independent CMS teams on their clients' behalf.
Cheers, J-P -- J-P Stacey +44 (0)1608 811870 http://torchbox.com
-- 2bits.com http://2bits.com Drupal development, customization and consulting.
FWIW. Take a look at http://drupal.org/node/131524 [1] for some common methods for working with external data. If you're in Barcelona, I will be addressing this again in the session "Using External Data with Drupal." I'm also going to have the "Enterprise Drupal" talk (again). Only this time there is no debate element. :-) - Ken Rickard agentrickard [1] And the download http://ken.therickards.com/wp-content/uploads/2007/03/OSCMS.pdf On 8/16/07, J-P Stacey <jp.stacey@torchbox.com> wrote:
Tao Starbow wrote:
This is one of the cooler, not-so-well known drupal features. In settings.php you can define $db_url as an array $db_url['default'] = normal drupal string $db_url['backoffice'] = other mysql connect string
then you use db_set_active( db_key ) to switch between them as needed.
Is this a standard core feature, enabled by default? I feel like saying "why wasn't I told about this before?" :)
One of the big problems we have is that many developers working on a given codebase: this means the codebase is in subversion and people check it out to their own machines, work on it, check changes back in.
Some developers develop on the same machine, because their desktops are WinXX and setting up LAMP stacks takes time. On this machine, whilst they can check out site-specific codebases to e.g. sites/developername-clientname-devel.example.com and hence develop in their own sandboxes, it's difficult to keep the site under revision and yet not have people be forced to share a database by settings.php .
But with the above a high-priority module could switch quickly and cleanly between developers' own sandboxed databases: does that sound right? How would you sneak in before any of the other modules? Would the following at the end of settings.php be sufficient:
db_set_active($_SERVER['HTTP_HOST']); // defaults to 'default'
Or is that too hacky? Can you even call a function from within settings.php (notwithstanding the argument of "would you want to?")
Somewhere among all this is functionality to make Drupal a good deal more "enterprise", for whatever that hackneyed term is worth. Transparently distributed development for large-scale, independent CMS teams on their clients' behalf.
Cheers, J-P -- J-P Stacey +44 (0)1608 811870 http://torchbox.com
Hi Ken, Quoting Ken Rickard <agentrickard@gmail.com>:
If you're in Barcelona, I will be addressing this again in the session "Using External Data with Drupal."
I'd love to be (and thought for about thirty seconds that the timing would be perfect until rechecking the con website) but unfortunately I'm passing through Barcelona precisely four weeks too late, to go to my dad's 65th birthday. I can't really take the holiday twice, much as I'd like to. Are there any plans for live blogging/podcasting/videocasting the event? It'd be great for the community as a whole to be able to tune in while still saving the planet (sort of). If there are any plans, a drupal.org announcement might bring them to wider attention. (I'll need to try to get IRC and identd working at home before Sep 22....)
I'm also going to have the "Enterprise Drupal" talk (again). Only this time there is no debate element. :-)
Aha. In Stalinist Drupal, code maintains *you*! Cheers, J-P ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On 8/15/07, Ron Dorman <rwd@simplydigtech.net> wrote:
FGM wrote:
If it's only two pages, why don't you just rewrite them in PHP ?
I would love to to. I have built php that connected directly to MSSQL on a backoffice system. I have never before thought about having php connect to two different db servers in the same app.
We would use the MySQL on the client server for Drupal, then need to connect to the 3rd party MSSQL for the small bits of data from the 3rd party inserted into the two pages.
I have not seen that Drupal has the capability to support and connect to two different db's. Is there such capability I have not found yet?
It exists, but has some caveats (mainly you have to set active to another db, and remember to set it back to Drupals afterwards). http://api.drupal.org/?q=api/function/db_set_active/HEAD
Beyond this, the question is what these ASP (raw ASP, or ASP.NET ?) data
are: you might also want to modify the ASP pages so that they export their data to Drupal over SOAP: SOAP integration is integral to both ASP.NETand PHP5.2, and writing a SOAP server in PHP is trivial.
The current pages are raw ASP. But again, one is the main/home page. If the sites is accessed with a sub-folder in the URL (www.example.com/sub1) the ASP (index.asp) page reads the backoffice server for a registered associate with an ID of the sub-folder name. If it finds such an associate, it inserts the associate name into the template for display throughout the site and sets a cookie with the associate ID in it. To run Drupal, we need index.php to be first in line preempting the index.asp page.
I would have to modify Drupal to get the data from the 3rd party server before rendering the initial page.
----- Original Message ----- From: "Ron Dorman" <rwd@simplydigtech.net> To: <development@drupal.org> Sent: Wednesday, August 15, 2007 8:00 PM Subject: [development] ASP Integration with Drupal?
A client wants to move an existing site to Drupal.
The catch is that the existing site has two pages that are ASP. The ASP pages connect to a 3rd party hosted backoffice package and database.
The clients current site is on a dedicated leased Win / IIS / Plesk Control Panel server. The Plesk package provides php 5.2 and MySQL 5 so I do not believe we will have any issues installing and running Drupal on the server.
Does anyone know of any development, module, etc. that would allow us to integrate the ASP data into Drupal?
Any other gotchas I should be looking for?
Thank you all for the work you do and for the Drupal software.
Ron D.
-- Ron Dorman Simply Digital Technologies www.simplydigtech.net rwd@simplydigtech.net 817-503-7704 ofc 817-503-7719 fax 817-528-8947 cell
-- 2bits.com http://2bits.com Drupal development, customization and consulting.
Khalid Baheyeldin wrote:
On 8/15/07, *Ron Dorman* <rwd@simplydigtech.net <mailto:rwd@simplydigtech.net>> wrote:
FGM wrote: > If it's only two pages, why don't you just rewrite them in PHP ? >
I would love to to. I have built php that connected directly to MSSQL on a backoffice system. I have never before thought about having php connect to two different db servers in the same app.
We would use the MySQL on the client server for Drupal, then need to connect to the 3rd party MSSQL for the small bits of data from the 3rd party inserted into the two pages.
I have not seen that Drupal has the capability to support and connect to two different db's. Is there such capability I have not found yet?
It exists, but has some caveats (mainly you have to set active to another db, and remember to set it back to Drupals afterwards).
http://api.drupal.org/?q=api/function/db_set_active/HEAD Thank you Khalid. Good info, but no support for the3rd parties MSSQL server in Drupal's abstraction layer, although I think I remember that someone was working it.
This may be a good starting place, thanks. Ron D.
I have an intranet application based on Drupal and connecting to Oracle 8i (Sage business app): I found it simpler to ignore the Drupal DB layer for everything Oracle related and just use PDO. It avoids both the issues of having to switch back and forth between active DBs and the need to backport the Drupal Oracle layer to Oracle 8. You might want to consider a similar approach. ----- Original Message ----- From: "Ron Dorman" <rwd@simplydigtech.net> To: <development@drupal.org> Sent: Wednesday, August 15, 2007 9:53 PM Subject: Re: [development] ASP Integration with Drupal? [...]
http://api.drupal.org/?q=api/function/db_set_active/HEAD Thank you Khalid. Good info, but no support for the3rd parties MSSQL server in Drupal's abstraction layer, although I think I remember that someone was working it.
This may be a good starting place, thanks.
Ron D.
On 15 Aug 2007, at 8:40 PM, Khalid Baheyeldin wrote:
It exists, but has some caveats (mainly you have to set active to another db, and remember to set it back to Drupals afterwards).
doesn't support multiple db types in one session either. namespace conflict in db api
adrian rossouw wrote:
On 15 Aug 2007, at 8:40 PM, Khalid Baheyeldin wrote:
It exists, but has some caveats (mainly you have to set active to another db, and remember to set it back to Drupals afterwards).
doesn't support multiple db types in one session either.
namespace conflict in db api
OK, Thanks Adrian. You just saved me some time and frustration Ron D.
On 8/15/07, Ron Dorman <rwd@simplydigtech.net> wrote:
FGM wrote:
If it's only two pages, why don't you just rewrite them in PHP ?
don't have the heart to erase that :) ... ...
I have not seen that Drupal has the capability to support and connect to
two different db's. Is there such capability I have not found yet?
right out of the box (set up in settings, array instead of scalar of course; function to switch db contexts). and I know this how? I'm so smart because I read the Drupal Pro Development book, chapter 5, http://drupal.org/node/100632 saludos, Victor Kane
Victor Kane wrote:
On 8/15/07, *Ron Dorman* <rwd@simplydigtech.net <mailto:rwd@simplydigtech.net>> wrote:
FGM wrote: > If it's only two pages, why don't you just rewrite them in PHP ? >
don't have the heart to erase that :)
Yeah, I wish it were that simple, I'd already be done with it. One of the pages is no problem. The other one, the main/home page of the site grabs two pieces of info from the3rd parties MSSQL server and inserts it into the template and a session cookie. Since ASP and php do not share session info, I have to find, or create, something to pass it across.
... ...
I have not seen that Drupal has the capability to support and connect to two different db's. Is there such capability I have not found yet?
right out of the box (set up in settings, array instead of scalar of course; function to switch db contexts). and I know this how?
Yes, it looks like a god starting point, but our abstraction layer does not yet support MSSQL (3rd parties db server)
I'm so smart because I read the Drupal Pro Development book, chapter 5,
Thank you for the book pointer, I had not seen it before. Now I'm going to spend some money. Ron D.
[snip] On Wed, Aug 15, 2007 at 02:26:00PM -0500, Ron Dorman wrote:
Beyond this, the question is what these ASP (raw ASP, or ASP.NET ?) data are: you might also want to modify the ASP pages so that they export their data to Drupal over SOAP: SOAP integration is integral to both ASP.NET and PHP5.2, and writing a SOAP server in PHP is trivial.
The current pages are raw ASP. But again, one is the main/home page. If the sites is accessed with a sub-folder in the URL (www.example.com/sub1) the ASP (index.asp) page reads the backoffice server for a registered associate with an ID of the sub-folder name. If it finds such an associate, it inserts the associate name into the template for display throughout the site and sets a cookie with the associate ID in it. To run Drupal, we need index.php to be first in line preempting the index.asp page.
I would have to modify Drupal to get the data from the 3rd party server before rendering the initial page.
Maybe you can use hook_init() (http://api.drupal.org/api/function/hook_init/5) Write a module implementing that hook, query your MSSQL server and set whatever you want in the $_SESSION array ? then your theme can use it ? If it's only for displaying, I'd even do it on the theme level ;-) -- GPG-Key: 0xA3FD0DF7 - 9F73 032E EAC9 F7AD 951F 280E CB66 8E29 A3FD 0DF7 Debian User and Developer. Homepage: www.foolab.org
Another aspect I did not specifically answer this part: in IIS you can specify the order in which default files are used. While it will normally place Default.asp first, you can reorder the defaults to place index.php first, so that any request for http://www.example.com/ is processed by Drupal's index.php. And from there, you can still invoke www.example.com/Default.asp explicitly, and the ASP app should work normally. Actually, although it would be rather awful performance-wise, I suspect you could just as well pipe the ASP page through Drupal for paths processed by that application. The issue of cleans URL will remain, though. I'm not sure ISAPI_Rewrite will be compatible with this set of rewritings, or whether there is an alternative. ----- Original Message ----- From: "Ron Dorman" <rwd@simplydigtech.net> To: <development@drupal.org> Sent: Wednesday, August 15, 2007 9:26 PM Subject: Re: [development] ASP Integration with Drupal? [...]
associate ID in it. To run Drupal, we need index.php to be first in line preempting the index.asp page.
I would have to modify Drupal to get the data from the 3rd party server before rendering the initial page. [...]
On Wednesday 15 August 2007, Ron Dorman wrote:
FGM wrote:
If it's only two pages, why don't you just rewrite them in PHP ?
I would love to to. I have built php that connected directly to MSSQL on a backoffice system. I have never before thought about having php connect to two different db servers in the same app.
We would use the MySQL on the client server for Drupal, then need to connect to the 3rd party MSSQL for the small bits of data from the 3rd party inserted into the two pages.
I have not seen that Drupal has the capability to support and connect to two different db's. Is there such capability I have not found yet?
Drupal 5 and Drupal 6 can easily connect to two different databases of the same type (both MySQL or both Postgres). However, the Drupal database API doesn't support MS SQL right now anyway. However, there's nothing stopping you from opening up a connection to another database using mysqli_, mssql_, or PDO in your own code and bypassing Drupal's database APIs completely. I'm working on a project now where we have not one but 2 3rd party packages embedded in wrapper modules. One uses mysqli_ internally, the other uses ADODB internally. Works just fine. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Op woensdag 15 augustus 2007, schreef Ron Dorman:
A client wants to move an existing site to Drupal.
The catch is that the existing site has two pages that are ASP. The ASP pages connect to a 3rd party hosted backoffice package and database.
The clients current site is on a dedicated leased Win / IIS / Plesk Control Panel server. The Plesk package provides php 5.2 and MySQL 5 so I do not believe we will have any issues installing and running Drupal on the server.
Here is how I "integrated" a python system, and a Ruby 'app': One approach: fopen() * put the asp pages on a localhost, or none-web-accessible place, then do a fopen(), optionally cache the result in the Drupal DB and print the result. Simple. Hackish but works in less then 10 minutes. Second approach: exec() * find out if asp has options to run over a CLI. php can do it, ruby, python and all the others too, so I gues (well, something tells me not to be to sure...) asp has something for this. FRom within php you exec() a local application, being the asp pages, optionally cache the result in the Drupal DB and print the result. Less hackish and probably requires some changes to the ASP code.
Does anyone know of any development, module, etc. that would allow us to integrate the ASP data into Drupal?
Any other gotchas I should be looking for?
Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Bèr Kessels wrote:
Op woensdag 15 augustus 2007, schreef Ron Dorman:
A client wants to move an existing site to Drupal.
The catch is that the existing site has two pages that are ASP. The ASP pages connect to a 3rd party hosted backoffice package and database.
The clients current site is on a dedicated leased Win / IIS / Plesk Control Panel server. The Plesk package provides php 5.2 and MySQL 5 so I do not believe we will have any issues installing and running Drupal on the server.
Here is how I "integrated" a python system, and a Ruby 'app':
One approach: fopen() * put the asp pages on a localhost, or none-web-accessible place, then do a fopen(), optionally cache the result in the Drupal DB and print the result. Simple. Hackish but works in less then 10 minutes.
Second approach: exec() * find out if asp has options to run over a CLI. php can do it, ruby, python and all the others too, so I gues (well, something tells me not to be to sure...) asp has something for this. FRom within php you exec() a local application, being the asp pages, optionally cache the result in the Drupal DB and print the result. Less hackish and probably requires some changes to the ASP code.
Does anyone know of any development, module, etc. that would allow us to integrate the ASP data into Drupal?
Any other gotchas I should be looking for? Bèr, I like the way you think and operate. These solutions can be plugged into a user defined, php enabled, block and things work, maybe a few tweaks. Did you implement in some other way?
Get it functional quick. Then, if needed, you have time to do something different. Thank you, Ron D.
Op donderdag 16 augustus 2007, schreef Ron Dorman:
Bèr, I like the way you think and operate. These solutions can be plugged into a user defined, php enabled, block and things work, maybe a few tweaks. Did you implement in some other way?
Yes. In a module, with a hook_menu() implementation and a simple page. see page_example.module in the docs section in cvs. Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Bèr Kessels wrote:
Op donderdag 16 augustus 2007, schreef Ron Dorman:
Bèr, I like the way you think and operate. These solutions can be plugged into a user defined, php enabled, block and things work, maybe a few tweaks. Did you implement in some other way?
Yes. In a module, with a hook_menu() implementation and a simple page. see page_example.module in the docs section in cvs.
OK, thank you Bèr.
I have done a ton of MSSQL integration with drupal. Here's the strategies I use. 1. When directly connecting to MSSQL databases, I actually use the ADODB library. It's really similar to the ADODB stuff you find in ASP so it makes porting a breeze. If you're using PHP 5 you can foreach iterate the returned record sets. I chose this library because it's a good platform agnostic way of getting at DB's but doesn't confuse the issue with drupal. I use the drupal API's for all things non-database. It doesn't conflict at all with drupal's stuff. 2. I also have written several .NET consuming apps in a REST web services style to consume data from the ASP or .net apps. The ASP (or .NET) pages simply display (based on get or post parameters) either hand rolled XML or key value pairs like on a URL parameter var1=foo&var2=bar etc. Which you choose depends on the complexity of the data. Again PHP 5 is a big bonus here for the parsing of XML (simplexml rocks for this). I have some students at my school developing an integration module for a 3rd party app with a that might be simple enough too illustrate the direct DB connect option. I'd be willing to send on a sample module if that would help you out. FYI: ADODB is a php only library, so installing it is a breeze. It layers on the normal php db functions. I've also successfully run ADODB connecting to mssql on windows platforms. On Aug 15, 2007, at 11:00 AM, Ron Dorman wrote:
A client wants to move an existing site to Drupal.
The catch is that the existing site has two pages that are ASP. The ASP pages connect to a 3rd party hosted backoffice package and database.
The clients current site is on a dedicated leased Win / IIS / Plesk Control Panel server. The Plesk package provides php 5.2 and MySQL 5 so I do not believe we will have any issues installing and running Drupal on the server.
Does anyone know of any development, module, etc. that would allow us to integrate the ASP data into Drupal?
Any other gotchas I should be looking for?
Thank you all for the work you do and for the Drupal software.
Ron D.
Thank you David. It appears that you have already accomplished what I need to. At this point, I am leaning toward your strategy #2. There is not much data to be passed from the 3rd party MSSQL into Drupal. However, that few fields of data are critical to the clients associate program. Once I break away from the 3rd party prescribed and provided methods, I will loose any and all support of the 3rd party backoffice software provider. Drupal is too good a solution for the client needs to let this be a show stopper. I have not yet received approval from the 3rd party provider for a direct connect to their db outside of the provided ASP, I am hopeful that will happen. This is part of why I am leaning toward strategy #2. I am thinking: strip down the current ASP pages to just grab the needed data, transparent to the end user, and feed it back into Drupal for use and display. I just haven't figured out how to make this happen within Drupal. A sample module will be very much appreciated and hopefully help others as well. Ron D. David Metzler wrote:
I have done a ton of MSSQL integration with drupal. Here's the strategies I use.
1. When directly connecting to MSSQL databases, I actually use the ADODB library. It's really similar to the ADODB stuff you find in ASP so it makes porting a breeze. If you're using PHP 5 you can foreach iterate the returned record sets. I chose this library because it's a good platform agnostic way of getting at DB's but doesn't confuse the issue with drupal. I use the drupal API's for all things non-database. It doesn't conflict at all with drupal's stuff.
2. I also have written several .NET consuming apps in a REST web services style to consume data from the ASP or .net apps. The ASP (or .NET) pages simply display (based on get or post parameters) either hand rolled XML or key value pairs like on a URL parameter var1=foo&var2=bar etc. Which you choose depends on the complexity of the data. Again PHP 5 is a big bonus here for the parsing of XML (simplexml rocks for this).
I have some students at my school developing an integration module for a 3rd party app with a that might be simple enough too illustrate the direct DB connect option. I'd be willing to send on a sample module if that would help you out.
FYI: ADODB is a php only library, so installing it is a breeze. It layers on the normal php db functions. I've also successfully run ADODB connecting to mssql on windows platforms.
On Aug 15, 2007, at 11:00 AM, Ron Dorman wrote:
A client wants to move an existing site to Drupal.
The catch is that the existing site has two pages that are ASP. The ASP pages connect to a 3rd party hosted backoffice package and database.
The clients current site is on a dedicated leased Win / IIS / Plesk Control Panel server. The Plesk package provides php 5.2 and MySQL 5 so I do not believe we will have any issues installing and running Drupal on the server.
Does anyone know of any development, module, etc. that would allow us to integrate the ASP data into Drupal?
Any other gotchas I should be looking for?
Thank you all for the work you do and for the Drupal software.
Ron D.
-- Ron Dorman Simply Digital Technologies www.simplydigtech.net rwd@simplydigtech.net 817-503-7704 ofc 817-503-7719 fax 817-528-8947 cell
On 8/15/07, Ron Dorman <rwd@simplydigtech.net> wrote:
I am thinking: strip down the current ASP pages to just grab the needed data, transparent to the end user, and feed it back into Drupal for use and display. I just haven't figured out how to make this happen within Drupal.
A sample module will be very much appreciated and hopefully help others as well.
I would take a look at modules that use external APIs such as Flickr[1] for pointers. Essentially wha you're doing is stripping down the ASP output to a web service ( plain text, xml or even JSON ) and then implementing a server-side-proxy for that data in Drupal. Make sure you use curl instead of fopen as it is much faster. cheers, JeffG [1] http://drupal.org/project/flickr
And cache the results of whatever you fetch. No need to grab that data on every page load. - Ken RIckard agentrickard On 8/16/07, Jeff Griffiths <anisotropic@gmail.com> wrote:
On 8/15/07, Ron Dorman <rwd@simplydigtech.net> wrote:
I am thinking: strip down the current ASP pages to just grab the needed data, transparent to the end user, and feed it back into Drupal for use and display. I just haven't figured out how to make this happen within Drupal.
A sample module will be very much appreciated and hopefully help others as well.
I would take a look at modules that use external APIs such as Flickr[1] for pointers. Essentially wha you're doing is stripping down the ASP output to a web service ( plain text, xml or even JSON ) and then implementing a server-side-proxy for that data in Drupal. Make sure you use curl instead of fopen as it is much faster.
cheers, JeffG
Ron Dorman wrote:
A client wants to move an existing site to Drupal.
The catch is that the existing site has two pages that are ASP. The ASP pages connect to a 3rd party hosted backoffice package and database. I thank you all for the responses and the learning I gained.
This is a great group of people to work with. Ron D.
participants (19)
-
adrian rossouw -
Bèr Kessels -
Chris Johnson -
David Metzler -
Earnie Boyd -
Eric Hole -
FGM -
J-P Stacey -
Jeff Griffiths -
jp.stacey＠torchbox.com
-
Ken Rickard -
Khalid Baheyeldin -
Larry Garfield -
Mohammed Sameer -
Neil Drumm -
Ron Dorman -
Steven Jones -
Tao Starbow -
Victor Kane