lol... ive never done that before...?

i'm a noob - is there anywhere to learn this?

This shouldn't affect display speed, it's all on the admin side.

The best way for THIS hack, I think, is as I kind of went into above:

Have ONE text area on the submit page.

Instead of one submit button, have two - one that says submit, one "Next Page" or "Continue" or whatever.

If the user hits submit, that means they are done adding pages, and the article is submitted exactly as it is done now.

If they hit "Next Page", then you have a subroutine that:

Submits the textarea data in the form to it's space in the db table.

Brings up a new window, textarea field called p2 like you have it now.

And so on.


OR

Have it be all one page for submitting the form/textarea data, and have the user insert a custom tag like <pagebreak> or something where they want new pages to start. Adding a button to do that automatically in HTMLArea - so the user just puts the cursor where they want the new page to start and clicks "New Page" - is so simple it's not even funny.

Now, I know you are worried about load, and that is a valid concern of course. However, you are missing something here. The <pagebreak> tag I talk about above isn't something that gets processed every time someone views an article. It's post-processing done when you submit the article. In fact, your article.php and the rest of your code won't need to be modified at all. Just the add article file.

What you do is add a routine for the pagebreak tag, and have each section submit to your table/pages. Something like this:
Would work. Use spliti to split the text for you (spliti is case-insensitive unlike split). Now you have php doing all the work for you when you submit an article. And as I said, this is NOT done on the viewing side - it doesn't change a thing. This is all done on the submit side.

If you want, when you get your latest changes uploaded (you really need something to handle categories, but you already know that) I'd be happy to work on part of this for you. Just let me know.

Go to your admin cp.

Scroll down to where you see "Import and Maintenance"

Click it.

Click "execute a SQL query".

Paste in the text from the articles.sql file.

Done.

BACK UP your database first.

could this be from installing phpMyAdmin tonight??? :\

please help - i would like to get this articles program up and running!

No, phpadmin would have nothing to do with it. But if you have phpadmin why aren't you using that? Use the SQL option on the vbulletin db and paste the text in there.

I think, now that I think about it (pun!) that vb's sql query feature restricts you to one query at a time. That's probably the issue there.

Hi everyone -

A small problem which may also need correcting in a future release ...

Like many people I choose to adopt a prefix when setting up database tables to identify which script they belong to - this is an option for VBulletin, of course.

However, this causes a problem with articles.php in at least one SQL statement (c line 35) where hard reference is made to 'thread', one of the (unprefixed) VB table names. (The prefix setting config.php in /includes doesn't figure in the proceedings ...) There may well be other instances

Thanks K and everyone else helping this project through!

Jon

when I call up the forum/articles.php all I get is a white page. I've looked over the install instructions and everything looks correct... but seeing that I'm an extreme noobie to this stuff, I don't know. Any thing I need to look at specifically?

Thanks

Did the template files you created go into the right style?

Yes, I only have one available to the members.

i'm still trying to set it all up (phpMyAdmin)... but this stuff is confusing! lol

when i try to set THIS up i get THIS error lol...

i thought i edited the config file right... guess not... im not sure how to connect it to my database..