[rt-users] Interfacing with RT via PHP

Chris Knipe savage at savage.za.org
Mon Jun 17 15:55:57 EDT 2002


> >1) It's a PHP based application.  I'm not going to rewrite over 3 million
>
> 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?

Yes, I could.  But HTML is static, the moment I make a change which would
affect the web site on a global manner, I'm faced with the odd single html
file to change here, or the odd cgi file to change there.  At the end of the
day, all of this adds up and I'll be back at sitting with 10ths of houndreds
of files that I need to change manually to reflect the changes in the file.

A good EXAMPLE (I don't do this, it's silly), is for example when you change
the background of your web site on every single page that is part of your
web server, via the use of a global PHP function.  It's very in depeth with
PHP, but I may have a global_prepend file, which is pre pended to every
single PHP file on my web server, which defines various "global" functions
used throughout my web site (this is what I am doing).

The global functions has various functions used throughout the site, writing
the templates for the pages.  The moment I feel like changing a template, or
inserting a new image to a template, or even using changing data (like
weather information for example), I merely change it in one place, in the
global function.

So at the end of the day, I write a complete web page, in less than 10
lines...

<?  WritePageStart("page title", "page description", "keywords"); ?>
my content for the page
<? WritePageEnd(); ?>

As you can well imagine, this saves me a TREMENIOUS ammount of time.  Even
more than simply copying and pasting, because when and if I should ever
change something, I change it in one single location - no where else.

> >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
>
> 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).

And you don't really come up here to defend mod_perl either.  Which just
prooves my point that the module is somewhat silly and awkward.  I must
admit though, my complaints regarding the module, can hardly be put as
frustration.  I don't allow myself to reach that stage, because I have way
more than enough stress in my life as it is.  I gave the module a try, I ran
it over a period of 14 days, and a pretty stable FreeBSD server slowed down
to a crawl, similar to running Windows 2000 Advance Server on a 166MMX with
128MB RAM <-- would be a accurate comparison.  Furthermore, the server
CRASHED twice during the 14 days, when the server previously had uptime of
way over 60 days.  That alone, was more than enough for me to have VERY
serious doubts about mod_perl, and hence my whole issue against running the
module.

I haven't looked at FastCGI yet as you said.  I do know that some mod_perl
stuff runs under it, but I didn't have the time to play arround with it yet,
no.  I'll definately do so in the near future.

> >6) Perl apps via CGI, I don't want to use either... If I change the
layout
>
> 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.

Yeah, I've explained it at the begining... prepend_file and append_file is
two very nice features of PHP when you have dedicated servers for web
sites.... :-)

> 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.

I saw some references to insert_ticket or something like that.  They should
be defined somewhere in one of the perl modules that came with RT.  I
haven't looked yet though, I thought I'd ask first before going in to much
details to do it myself.  There's no use in re-inventing the wheel is there?
As to what you said earlier regarding getting the ticket number out of the
database....  It's probably the easiest thing to do.  Both in perl and
mysql.  The ticket number is stored in a auto_increment column in MySQL,
perl and PHP has built-in functions that allows you to retrieve the
auto_increment value on anydata that you insert...  i.e....

$sql = mysql_query("insert into table (column) values ('1')")
$autoid = mysql_id("$sql);

I can't remember of the tip of my head what the function's called in mysql,
but the code looks something similar to that.  I'm doing it with quite a few
other areas of my web application with great success.

--
me


> 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
> >
>
> _______________________________________________
> 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
>





More information about the rt-users mailing list