IPB Output Method

[Sean Matula]

For Site Integration purposes, it would be neat if IPS developed an intermediary class that receives input (GET) strings, and returns IPB

[Rikki]

I'm not sure if it will do exactly that, but IPB will soon have a new feature called HTTP-API, which will allow you to interact with IPB via GET requests to perform actions such as posting topics, replying etc. That might be of use to you :)

[Dlf]

Sorry if this isn't allowed. But this is a entry/post from Matt's blog (mattmecham.com):

A party inside?
A persons IQ?

Nope. Application Programming Interface. This exciting term encapsulates the ability to interfere with a program without having intimate knowledge of the program's code. Good idea, I say.

With this in mind, I've started work on IPB 2.1's API. Now, fundamentally IPB has core classes, of which an API layer is wrapped around then and then another layer wrapped around that called 'HTTP-API'. The HTTP-API wrapper will allow one to fire off commands via the wonders of POST or GET. When correctly configured, you'll be able to update your member's signature with a command as insanely easy as "httpapi.php?api=members&-save-signature=hax&id=32&apikey=hilariously

longkeyhere'. This further abstracts one from the realities of getting one's hands dirty with nasty old PHP code.

However, before we get all carried away with that, we first need a good solid API structure which interfaces with the IPS classes without re-creating too much code. Our utopian fantasy would involve lots of naked women, I mean, it would involve being able to write a whole suite of API classes and then write a framework called IPB that uses them. However, this is still a relatively distant dream simply because the average forum system is one big bad-ass hack. Programming theory and the reality of cramming 350 accounts on a P4 web server don't often run along the same lines. The average forum system (and indeed, the average web application) takes advantage of several short-cuts to reduce the number of loaded classes and queries. This isn't ideal but the having your program banned is less desirable.

So, I've had to suffer a little duplication. Originally I had planned to make the Posts API directly load class_post.php functions but class_post.php is only really set up to deal with the current logged in member (something that will be addressed in IPB 3.0) and thus not useable. Fortunately, I've been able to make use of class_post in other areas, such as topic rebuilding, forum rebuilding, stats rebuilding, topic tracking and forum tracking meaning the only real duplication we have is with the actual data insertion. Good enough until I go through the code during IPB 3.0's development cycle.

Here's how easy it is to add a reply to a post:

$api = new api_topics_and_posts();
$api->set_author_by_name('matt');
$api->set_post_content("Hello World! :D");
$api->set_topic_id( 100 );
$api->create_new_reply();


And topics...

$api->set_author_by_name('matt');
$api->set_post_content("Hello World! :D");
$api->set_forum_id( 10 );
$api->set_topic_title('Hello World');
$api->create_new_topic();

[Sean Matula]

It's worth taking a look at. So far, I've tried and failed to get this done many times. I've tried fopen, fsockopen, and a variety of 3rd party HTTP classes. Most of them can successfully open and grab the processed HTML from the default (no GET) page; but none of them successfully load any other pages (like

[Sean Matula]

Ok...

I'm using the Snoopy class to fetch the pages; and its working to the point where "showforum=2" will print out forum 2. However, (I think) because I'm calling from root folder (and IPB is in the "forums" directory) I'm throwing off user validation. Any thoughts on this?