[Pmwiki-users] passing variables between php programs

[Crisses]

> Pmwiki isn't designed to take data from other scripts, at least not
> natively. I'm not sure if you can pass it GET variables on an edit page
> for content, proably not. You will need to find where in Pmwiki the 
> edit
> page is rendered and make it look for a specific GET variable if that
> variable exists then just propagate the edit form with that variable
> instead.

This is the relevant HTML:
   <form action='http://www.kinhost.org/wiki/Main/AllRecentChanges' 
method='post'>
   <input type='hidden' name='pagename' value='Main.AllRecentChanges' />
   <input type='hidden' name='action' value='edit' />

   <textarea name='text' rows='25' cols='60'
     onkeydown='if (event.keyCode == 27) event.returnValue=false;'
     >

So a variable called "text" is sent by POST to PmWiki.  It's verified 
by a Javascript, but if I submit via another program I'd be bypassing 
that client-side technology.  Also sent is the "pagename" variable with 
the name of the page, and the "action" variable with the value "edit"

I've been looking at cURL [which has a PHP binding] and at PEAR's HTTP 
libraries -- cURL definitely has the capacity to send a POST, and I've 
been learning why it's different than GET.  PEAR is way over my head 
right now, I think.

> Sorry php.net is a good reference for those already familiar with
> programming languages and php. If your just learning php this type of
> modification to Pmwiki will probably be a difficult task, you will need
> to read the code to find out where to make your modifications.

I know PHP but it has a long list of libraries and similar 
(class-action LOL) add-ons.

The problem was in my knowledge of how POST works.  Post is an entirely 
separate HTTP "request" packet from a request for a HTML page.  With 
only basic PHP functionality I'd have to jump through a lot of header() 
statements to send a POST request correctly (I think)...and if you've 
looked at the Functions list on php.net, it's rather long.  I poked at 
about 8 different function lists looking for what I wanted, but didn't 
find it because it's a little buried -- it's under cURL. 
http://www.php.net/manual/en/ref.curl.php and that's again not a great 
place to *learn*.

> There probably several very nicely written introduction to php books on
> the market that will help you learn. Or you may consider having someone
> else make these modifications for you.

I've got 2 PHP books.  I've read them cover-to-cover.  I have a few 
references but they only briefly mention the functions in some of the 
libraries.  The Peachpit books don't include this information, or I 
wouldn't have to pour over the web for it.  I've already learned PHP -- 
I haven't learned all the functionality provided by the extensions to 
PHP.  I'm not an expert at PHP, but I'm rather functional with it.  
I've never dealt with HTTP requests before, that's all.  I've been 
programming since 1985 with Basic on a commodore 64, moved to Pascal, 
Fortran, dBaseIII+, dabbled in Perl and now I'm doing PHP.  
Unfortunately procedural language makes a lot more sense to me than 
object-oriented programming which is why PEAR kinda loses me (and it's 
poorly documented that I can tell).  I don't understand why my asking 
for help in one area is interpreted as me not knowing PHP and needing 
some nice books.

> To add <br /> to the end of every line of a file you can simply use:
>
> str_replace("\n","<br />",$data);

Thanks, but that's already in the program.  and I'm using 
preg_replace() and $implode ($array, "<br />\n"); so my html doesn't 
come out looking like a gorilla wrote it.

That is not the code I was asking for help with.

>> I want to know how to pass that array to PmWiki.  I don't think it
>
> To pass a variable, array, or any kind of data via a GET variable you
> can simple serialize it then compress and encode that and pass the
> resulting string via GET then in the other script you will decode,
> decompress then unserialize the variable.

This is great advice, but will require Patrick to re-write PmWiki to 
accept the variable via GET and I don't want to do that.  However, it 
might be a great way for me to pass text around if I make any other 
stand-alone modules that are not interfacing with Patrick's program.

>> should be via GET; it's possibly going to get too big.  I need to know
>> how to send a POST to another url without using a hidden field on a
>> form with a button that necessitates user interaction.  I also want to
>
> I don't believe a url length has a maximum length, it is possible if
> your uploading HUGE files. The other option is to send the data via
> POST, but post requires the browser to submit the data via a form, this
> could be done automatically with javascript but it would make an
> intermediate page load up, a "loading" page.

I thankfully found it, and you are incorrect:
http://zend.com/zend/tut/tutorial-thome3.php
http://www.phpfreaks.com/tutorials/49/1.php
http://curl.haxx.se/libcurl/php/examples/?ex=customrequest.php

It does require that you put php's curl library into it.  It comes 
already on OS X and it's as easy as pie using dselect in Debian, but 
I'm not sure how hard that might be for anyone else.

>> incur the lowest amount of PmWiki being rewritten.  I'm not sure I
> need
>
> Pmwiki probably isn't designed to take data via GET and POST to display
> in the edit page form. So this would require a modification, not very
> extensive, just a few lines.

No modifications needed.  Of *course* it gets data from the client via 
GET --or-- POST because there's no other way browsers send 
data,[addendum: there is session data and cookies, but those also can 
be poked at, looked at, and hacked] which means *any* webpage can be 
hacked (in the Google or Ebay "Hacks" kinda way) using the cURL 
libraries if you're diligent enough and willing to put your passwords 
into [or pass them to] the program you're making.  If someone is using 
Java, that might change this case.  Javascript is only used in PmWiki 
to authenticate information before it is passed.  PmWiki doesn't 
actually know whether or not the javascript ran when it receives POST 
data.  PmWiki is not sitting and waiting on the server for the data to 
come back.  It get the data when the page is hit.

> I'm not sure if your wanting this to be done by yourself or if you want
> someone else to do it for you? I'm writing my responses in format
> presuming that you have at least some experience with php.

I just wanted an example of a POST if it were a simple one-liner (which 
it isn't quite that simple, apparently) or for someone to go "Oh, you 
need to either look at the cURL library or look at the PEAR project's 
HTTP_REQUEST features or their CLIENT somethingorother features."

>> I don't think base64 is going to help (I assume that's for purposes of
>> data compression?).  Are you implying the only way to pass variables
>> from PHP->PHP is via GET?  Or is it just the easiest way?  You never
>> actually said POST is not possible.  What if the text field is so
> large
>> it's too large for GET even after being encoded in base64?  And what
>> library do I find that command (to encode a string in base64) in?
>
> base64_encode doesn't compress, in fact if you encode something via
> base64 it usually grows slightly in size. To compress it you would use
> gzcompress() before you encoded it. Encoding just makes sure the string
> contains only legal characters that can be in a url.

Ah.  Well, that's not helpful because I'm not going to ask Patrick to 
rewrite PmWiki to accept base64 data.

> It is possible a huge file compressed this way and passed via a GET
> variable could cause problems. In that case you will need to use POST
> and some sort of JavaScript to auto submit the post data to the second
> script.

Again; this is incorrect.

> There is also php sessions that can be used to hold data. This doesn't
> require any GET and POST variables to pass data from page to page. All
> it does is sets a cookie on the user's machine and that cookie is read
> on each page view and then php looks up the cookie data and then auto
> loads up a master array that is the same from page to page.

That's true: session data and cookies are passed as well as GET and 
POST.  But if PmWiki isn't looking for 'text' via session or cookie, it 
won't find the data there, so this point is moot unless I'm looking to 
add and author name, password/id, etc. to the "session"

> $_SESSION variable is available once you enable sessions on a page. 
> This
> variable works like any other; you can set things in it and read from
> it, only this variable becomes available to php script on the site. 
> This
> is a feature few utilize in php. I'm not sure on its reliability and if
> the user doesn't have cookies enabled I'm not sure it will function.

I believe that PmWiki starts both a session and reluctantly plants a 
cookie.  My passwords expire when I close my browser, but my "author 
name" is there every time I use the site.  That implies that PmWiki 
does both.

>> I already have one: Antiword.  I appreciate it though.
>
> Is this a command line program? I merely suggested some programs that
> looked pretty powerful and was command line and unix compatible.

Yes :)  I compiled it on my OS X box, and I used dselect to put it on 
my debian server.  My OS X box is used for development/testing [because 
my iBook can go everywhere with me :) ] and my debian server [a G3 
beige running BootX -> Debian] is live on the net.

>> Again: are you saying it's not possible?  Or is it so hard it's not
>> worthwhile?
> No php can easily execute command line programs and read in files. This
> isn't' a very hard task.

I meant POST, not reading in lines and changing them.  My program works 
already.  It works great.  I just want the output in the wiki. and I 
don't want to be cut/pasting from a browser window into another browser 
window for the rest of my days as a recruiter.  Even if I had to use a 
form, pressing one button is easier than cut/pasting.  However, that 
shouldn't be necessary.  This should work seamlessly once I figure out 
exactly what PmWiki *needs* to have passed to it.

Thanks for your time and trouble.

Crisses