[rt-users] Interfacing with RT via PHP

Mon Jun 17 15:26:08 EDT 2002

AFAIK, Chris, you're more or less out of luck. It's not that somebody
else hasn't done this already (I don't know, maybe they have), but I
think a lot of people give up on PHP after they get more insight to
HTML::Mason and the design of RT. 

Also, I've replied some more throughout the text of your message:

Chris Knipe writes:
>1) It's a PHP based application.  I'm not going to rewrite over 3 million
>lines of code on a web application to allow me to insert data into a
>database via mod_perl.  That just morally isn't right, and doesn't make any
>sense to me what so ever.  Needless to say, it will be over a year's worth
>of work that I need to re-do....

That's a very good justification. However, you could still reference
an HTML page, couldn't you? Rewriting a year's worth of work sounds
bad, but I don't know why you'd need to rewrite it all, couldn't you
just link over to the HTML::Mason page?

But it appears you have other concerns listed below. And, of course,
you add complexity to the maintenance of your webserver by installing
RT and all its dependencies on there.

>2) Databases are universal, and they are accessible through various
>programming languages and APIs, which also motivates point 1 a bit more I
>think.

Yeah, but RT's API solves a lot of problems with accessing the database
directly. For example, good luck trying to query the database to find
out which ticket id you just inserted. Using RT's modules, when you
create the ticket, you have a return value that tells you that info.
I'm not sure there's a pretty way of doing it, but I'm not an expert,
either.

>3) I'd like to steer away from mod_perl on a production level (this is a
>personal opinion, and I have my right to express them).  While on non
>critical systems, I'm more than willing to use it.  From past experiences
>I've had with RT and mod_perl, I don't like the idea of having those high
>system loads when a RT web sites becomes very busy.  On our development
>system, while receiving +- 30 emails per minute, our system's 15 minute load
>average went up over 5.4.  I've also noticed this with load scenario with
>other mod_perl based applications I wanted to run, all of them resulted in
>the same, which tells me its a mod_perl issue, and not RT, so flames and
>wars here will kindly go to /dev/null.  The fact of the matter, is that I
>don't like mod_perl, and there is no way that I am putting this on a
>production system.

I don't know that anyone on this list will flame you for expressing
frustrations with mod_perl. :-) That's understandable. Mod_perl is
stinky, IMHO as well. I like fastcgi a lot better.  It improved
performance at my site significantly, though I'm still not using
fastcgi in production because the rt mason handler for fastcgi doesn't
do what I'd like it to do with cookies (and what the mod_perl mason
handler currently does, methinks).

You should consider giving fastcgi a try.

>4) mod_perl is also Unix specific, which may become a problem.  With a
>universal way of accessing the data, I can even integrate ASP (Win32) based
>sites, as well as C++ / Delphi programs to interface with RT.  This will
>also become a big problem at a later date, seeing that our company's
>internal management systems will be in Delphi / C++, and not web based.  So
>either way, this is going to become a problem for me over the next few
>months, seeing that PHP and Perl is not the only languages I need to give
>access to RT's data.

Don't know whether fastcgi is UNIX specific or not. I'm guessing it is.

>5) I can't simply email the ticket, because the ticket will be send back to
>the sender of the ticket itself.
>5.1) If this is sent to the user who submitted the form, I can't reference
>the ticket number on the site
>5.2) If it's sent back to the web server's user, there may be long delays
>until I am able to pop the mail from a mailbox to retrieve the ticket
>number, which can cause timeouts on the site (mail may be delayed in SMTP
>queues for example).  Neither of which, is a decent way of implementing
>this.

Yeah, emailing the ticket from the web is crappy, IMHO. I agree.

>6) Perl apps via CGI, I don't want to use either... If I change the layout
>or something of my site, I merely change one global function.  A CGI in this
>case, would need to be recoded completely, which limits me in regards to the
>functionality of the web applications I want to use...

Not sure what you mean here. I guess you're doing some kind of
site-wide include stuff for your pages. But it doesn't really matter
whether or not I understand, I think, since your other justifications
for using PHP are pretty substantial anyway.

>If there's a simple DB API available somewhere, or, if someone can simply
>provide some MySQL database logs of where RT data is inserted and retrieved
>from the database, the query is in there.  All you need to insert a ticket
>and get a ticket number to my understanding, is two simple database
>queries..... Or.. Am I mistaken?

You may want to look in $RTPREFIX/lib/RT/ for some of the code (if you
haven't already), but I spent about five minutes looking for it and
couldn't find the database insert stuff in there. And there are more
clueful individuals about than myself.

Anyway, I'd still encourage you to look at using fastcgi as opposed to
mod_perl because fastcgi's performed much better for me. But, if PHP's
a better fit for you, best of luck with it.

Matt

>Kind Regards,
>
>Chris Knipe
>MegaLAN Corporate Networking Services
>Tel: +27 21 854 7064
>Cell: +27 72 434 7582
>
>----- Original Message -----
>From: "Matt Disney" <matthew.disney at fedex.com>
>To: <rt-users at lists.fsck.com>
>Sent: Monday, June 17, 2002 7:27 PM
>Subject: Re: [rt-users] Interfacing with RT via PHP
>
>
>> What are your motivations for using PHP rather than HTML::Mason?
>>
>> A while back, since I wasn't comfortable with the state of RT's
>> unauthorized user interfaces, I created a PHP interface to simply email
>> a ticket in and then I linked to a NoAuth list of tickets in that
>> queue. I ditched it before we moved RT to production, though, in favor
>> of HTML::Mason stuff that is much better because it sits on top of the
>> RT API.
>>
>> I'll gladly provide the stuff I've done with HTML::Mason, but I'm
>> afraid there's not much I can help you with as far as PHP interfaces.
>>
>> Matt
>>
>> Chris Knipe writes:
>> >Hi all,
>> >
>> >Are there anything available that's written already to interface with
>RT's
>> >tickets via PHP?
>> >
>> >I'd like to have a type of system where I can inject a html form as a
>ticket
>> >into various RT queues.  For example, I may have a support form on a html
>> >page, where the user provides his / her email address, and  a detailed
>> >description of the problem.
>> >
>> >I'd like to then take the form data, inject it into RT, and provide the
>user
>> >with the ticket number over the web.
>> >
>> >Is this at all possible?  Anything written for it already?
>> >
>> >Kind Regards,
>> >
>> >Chris Knipe
>> >MegaLAN Corporate Networking Services
>> >Tel: +27 21 854 7064
>> >Cell: +27 72 434 7582
>> >
>> >
>> >_______________________________________________
>> >rt-users mailing list
>> >rt-users at lists.fsck.com
>> >http://lists.fsck.com/mailman/listinfo/rt-users
>> >
>> >Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm
>> >
>>
>> _______________________________________________
>> rt-users mailing list
>> rt-users at lists.fsck.com
>> http://lists.fsck.com/mailman/listinfo/rt-users
>>
>> Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm
>>
>

>_______________________________________________
rt-users mailing list
>rt-users at lists.fsck.com
>http://lists.fsck.com/mailman/listinfo/rt-users
>
>Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm
>