Search options (Page 7 of 13)

<-- Running lighttpd+sqlite3 (I coded the db layer to support sqlite3 myself, can't garantee it's 1.2.14 compatible, but it should work afaik)

Been a while since I last posted here... Anywhos, somewhere on these forums you'll probably run into "pdosqlite3 dblayer" or something along them lines. Download the tarball and follow the directions to add support for sqlite3 databases (which add a few improvements to sqlite 2 databases, the default with punbb 1.x). Converting from sqlite to sqlite3 is easy from a shell:

sqlite forum.db2 ".dump" | sqlite3 forum.db3

I've had a few problems with my computer and my time the past few months, and I am making the move to mysql (only because my e-mail server requires it; and because it's just as easy to backup the database iff you have shell access; and because of async requests - if sqlite3 supported async read/writing i'd probably stick with sqlite though ). So if anyone wants to take over the sqlite3 db layer "mod" your welcome to it.

EDIT --

Found it, here's a link to the topic:
http://punbb.org/forums/viewtopic.php?id=13123

And here's one to the tarball:
https://robshouse.no-ip.info/pdosqlite.tar.bz2

If the link doesn't work, I've probably buggered something up in my firewall config, so just post and tell me. I don't really have a computer outside the firewall to test with ;.;

EDIT --

Ohh, just to say, the reason I started to use punbb was because it supported SQLite. I started with lighttpd, then moved on to choosing a database, and finally choose a forum that supported my database (I think punbb is the only open source forum project that does, or at least the only one that will work ^.~).

SQLite(3, and 2 afaik) can do async read requests. It get's into trouble with major traffic if there is a write request. For the duration of that single write request, each read and/or write request will probably fail; From what I remeber both my version and the original version of the sqlite db layer set-up read/write access on every php page, and the translates into each single request being required to close before the next request for a page is allowed to be opened (or times out). Although, if you were crazy and felt like a quick hack, you ~could~ re-implement all the sqlite dblayer functions to retry on fail every 1 seconds for 15 seconds, and only open the db as read until a write statement is found. Since both 2 and 3 support the BEGIN TRANSACTION, COMMIT and ROLLBACK SQL statements this would be close to trivial, except for the parsing of each statement (which could be a SELECT or could be a UPDATE or any number of commands that may or may not require write access).

I personally feel that a more abstract DB layer should be made on top of the current layer. This would mean more CPU usage server side, but could facilitate database support for modules. http://punbb.org/forums/viewtopic.php?id=13125 for a fuller view of what I'm trying to say in to many mumbled words, and a few reasons why not to do it too ~.^ Also with this type of db layer databases could be opened and closed depending on which sql statement is about to be executed. Allowing a "only reading from db" php page to only open for reading. I think index.php, search.php and viewforum.php are the only pages that are read-only, but they are also probably the most used pages on any forum.

lol, sorry for the triple edit... seems my short post turned into a long one, but I have a few months of silence to make up for

copy and paste?

If there isn't an import for google, then have fun copyin' and pastin'. If there is an import, then I think your going to have to ask elsewere for a way to export a punbb database to a compatible format.

Strofanto already answered your question.

open include/functions.php

and look for the part that turns http://address into <a href="http://address">address</a>
Now, in the <a href="blah"> change it to <a target="_blank" href="blah">

Easy stuff

Because if I wanted to see his userlist as a guest and didn't see the link, I'd type in <forumaddress>/userlist.php

Ofcourse there is a better way, that's been discused before. erick_p, use the forum search tool and you'll find it... the topic was active yesterday or the day before and was about the same thing your asking...

Why people never use search, I don't know... The least they could do is say that they where to lazy to use search...

I was about to say, it looks like half of line 186 is missing
G'Luck with punBB

Just post your problems and we might be able to help... It's a much more efficient way to get helped since you have more people working on your problem...

What's the css look like? maybe there's a typo? have a link? and what colors were yah going for? blue text grey background and red links?

What 'bout us lazy admins who use SQLite? I don't think it's terribly close to supporting all of Standard SQL ~.~

The DBLayer is perfect though zaher, for making another dblayer. That's what I did first, had to write support for SQLite3 (only v2 is supported nativly with punbb). If anything, a second layer of abstraction could be used to "translate" from Standard SQL to <insert database type>, but that would add a fair amount of bloat. The only downside to the DBlayer is the fact that most modders only run and test thier mods for one DB type, so to support a different type another php/sql vete has to come along and add the support and then let the mod dev know.

hehe, my first php experiance was coding that dblayer, only took 7 days 5 websites 2 manuals and 27 coffees

Didn't see that I'm blind

You just need to know php/javascript/html/css ;p

More like "You try to shoot yourself in the foot, but misplace the foot, and the bullet hits your videocard, causing a permanent streak in your eye" ... not that that happend to me...