You are not logged in. Please login or register.
PunBB Forums → Posts by Louis
Ah, but couldn't there be a way to have both the private BBCode and a public BBCode/vCard-based thing? Therefore wouldn't using a few vCard fields for both simplify things?
If you aren't interested in a public vCard-supported interface to PunBB then fine. Do BBCard how ever you like. I like the idea of having PunBB support vCard though, so perhaps I'll work on a mod for that on my own, and if/when you finalize something for BBCard, I'll integrate it with that.
If you don't have a login to phpclasses.org, here's the first class I mentioned:
Also there are already two vCard classes posted at phpclasses.org, they don't just create vCard files, they parse them too:
http://iplexx.mirrors.phpclasses.org/br … /1035.html
http://iplexx.mirrors.phpclasses.org/br … /1023.html
Both are under the GPL.
Well, I didn't know that. However, having gone down this road, let's chat a bit more -- faced with all the things vCard support CAN do, why NOT do it? You don't have to implement the full vCard, you could just use it for name, email, time zone, fields that match up.
Also, you could create a separate script to generate vCard files (non-xml) from people's profiles, and add in their interests in the Comment property, adding a URL property for a link to their profile on the originating forum, or if you wanted to go farther, use X- fields for extensions to the vCard, like X-ICQ, X-MSN, X-AOL and X-YIM (Check to see if others have done this before, perhaps we can interop further)
It makes sense to me ... why re-invent the wheel? You don't even have to use XML to do it, with the X- extensions you could store it all in vCard.
There's more to vCard than you'd expect: http://www.imc.org/pdi/vcard-21.rtf
... And start coding the standalone version right now. Shouldn't be much work.
Release it under the GPL so we can make improvements on the code too ;)
And I really doubt that PunRes would use 20 GB of bandwidth ... most files on the site are over a couple hundred KB, at most.
Perhaps we should re-open the Mod sections on this forum then? They were never all that popular on PunRes because they were harder to find.
Examples of vCard support with Microsoft products:
You can use vCard vdf files in Outlook since 98:
http://support.microsoft.com/default.as … -us;290840
You can create contacts from vCards or even append them to your signature automatically:
http://support.microsoft.com/default.as … -us;248832
Since Internet Explorer 5, you can use vCard to auto-complete forms:
http://msdn.microsoft.com/library/en-us … /VCARD.asp
You can also grab vCard data automatically from the Profile Assistant:
http://msdn.microsoft.com/workshop/mana … istant.asp
Also, vCard is integrated with the Windows Address book, the Exchange server, Sharepoint profiles, and Longhorn contacts, including their new Tablet PC pen-optimized display. So contacts integration won't be going away anytime soon ...
Standards are definitely a good thing, use them as much as you can.
Louis: Then why involve VCard at all? It doesn't have a lot of fields that are of interest in a bulletin board so basically all fields will have to be extensions. Also, what I'm after is to have a "downloadable profile". You download you profile in a forum you are registered and then upload it when you register in another forum. VCard surely wasn't meant for such things. Sure, we can use RDF, but I can't see how involving VCard will help in any way.
It depends on how the BBCards are used. I figured it should be a standardized way to transfer contact info from email clients to instant messagers (like mranda or trillian, which support plugins) to forum software -- and not just PunBB. Perhaps it's more ambitious than this feature requires. However, from a standards point of view, even having vCard formatted fields for name and email means that it SHOULD work with email clients ... the whole idea of using standards are for interoperability, so I figured we could increase PunBB's use of standards a bit more. Your choice though.
The problem is that the converter is made for Invision Power Board 2.x, so there's some changes between the versions.
Well yes, for now, supporting 1.3 at minimum would be a good thing. It's difficult to get at 2.0 with their current website, and after downloading it and running the upgrade script, then modifying it to support the database, then realising this WASN'T going to work, I looked it up on google and found ...
This is the fourth IPB 2.0.0 development update. These updates are designed to keep you informed on the development progress of Invision Power Board v2.0.0.
We've almost completed IPB 2.0.0 PDR 3 and this is where things get quite exciting as we begin to wrap up the 'middle' part of the last stage of development and testing. So far we're very pleased with the progress and the great work in finding and reporting bugs.
(blah blah, new features, blah blah)
Latest Release Date Estimates
PDR3 (next beta release): Monday 17th May
RC1 (first supported release): Thursday 27th MayPlease note that these dates are only estimates and should only be used as a guide. They are subject to change without notice due to the unpredictable nature of software development. Put simply: they are dates that seem reasonable based on the current speed of development.
(More blah, blah)
Upgrading to PDR 3 from PDR 1 or 2
We have initiated our new upgrade system and a new upgrade module will be written for PDR 3.
Upgrading from 1.3 to 2.0.0
There is currently no upgrade path from 1.3 to 2.0.0. We plan on writing the upgrade script for around PDR 4 (Beta 4). Until then please don't try and import a 1.3 database into 2.0 - it simply won't work.
So it seems there's no way to upgrade right now to 2.0. We'll have to wait until the next release, which was supposed to be 3 days ago, but I guess it has been delayed.
Keep in mind:
1.3 is the current stable release and it is always recomended that you upgrade to the latest stable build. Also even if 2.0 comes out in a few weeks it wont be considered stable until it has been tested by a large customer base.
At this point I would not plan on upgraded to 2.0, dont even think about it until it is stable, unless you are willing to run a beta.
I know ibf's development cycles are fast but I would like to give you an example, last year I made the jump to vB 3 beta 3, a year later im still running the RC 3. RC's are considered more stable then beta's but it still isn't gold, so that site has been running 'beta' software for over a year now.
So I really would fix the 1.3 support, as I doubt people will be using 2.0 for another few months ...
Here's the PunBB database I managed to create
(without polls, sadly, because I couldn't install the PunPolls mod):
Joey: Don't use this link untill I've looked at it! /chacmool
http://www.CSpotkill.com/joey_punbb.sql.gz
Just create a new PunBB install, get it working with a database, then drop all the tables in the database PunBB is configured to use and load the above SQL instead. It will create the tables automatically and populate them with the data I managed to convert. Use PHPMyAdmin if you're unfamiliar with databases.
Arrgh! Why me? :/
When I load the PunRes site, my firewall says:
The page cannot be displayed
There is a problem with the page you are trying to reach and it cannot be displayed.Please try the following:
Click the Refresh button, or try again later.Open the Web site home page, and then look for links to the information you want.
If you believe you should be able to view this directory or page, please contact the Web site administrator by using the e-mail address or phone number listed on the Web site home page.
10060 - Connection timeout
Internet Security and Acceleration ServerTechnical Information (for support personnel)
Background:
When the server, while acting as a gateway or proxy, contacted the upstream content server, it did not receive a timely response.
Well, I tried. :/
If someone could have a look at it, it'd be much appreciated. Email in profile :)
It took about 10 minutes before I realised I had to put the converter in a subfolder in a punbb installation, then it took another 4 for me to use the mysql command line to insert the dump in a new database and give the punbb database access to the ibp database. Ugh I hate security sometimes.
File: _start.php
Line: 46PunBB reported: Unable to fetch user info
Database reported: Unknown column 'e.aim_name' in 'field list' (Errno: 1054)
Switching line 46 in _start.php and line 8 in _users.php to the following fixed the error:
$res = $db->query('SELECT m.* FROM ...InvPB to PunBB converter at page: _polls
Converting polls: 0...
PunPoll not installed, redirecting...
Never redirected me. Had to manually change to ?page=6 from ?page=5
File: functions.php
Line: 9PunBB reported: Unable to get count value for table: badwords
Database reported: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 (Errno: 1064)
After staring puzzled at the code for a bit, I realised it was because there was nothing inside the ibf_badwords table for the script to convert. Better add a check or something to that.
Oh and it's not "cencored" or "cencoring" but "censored" and "censoring" ;)
Next on to ?page=7 (manually typed, because of the above error)
File: _bans.php
Line: 5PunBB reported: Unable to get posts
Database reported: Table 'invpb.ibf_banfilters' doesn't exist (Errno: 1146)
No problem, I'll assume he just didn't ban anyone. Needs another check or something to avoid the error message though.
Next on to ?page=8 (manually typed again because of the error)
Info
Conversion done!Database converted in: 1085865131.97s
Note: Don't forget to rebuild the search index!
PunBB status
PunBB contains:
Users: 155
Categories: 8
Forums: 0
Topics: 248
Posts: 5028
InvPB status
InvPB contains:
Users: 157
Categories: 8
Forums: 0
Topics: 248
Posts: 5028
Polls: 23
Because your board contains polls (and I didn't have the polls mod installed) I'll re-do this, to get the polls done too, then create an sql dump of it, if you want.
armpits
Yeah, it's really hard to fix the bugs if no one tells me they exist :)
Testing, testing, testing :)
http://www.google.com/search?q=php+unit+testing
Plush toys
Louis: Contact Paul and I'm sure he'll demonstrate the changes he has done so far.
Okay, check your email, Paul :)
You can download language packs for PunBB from the downloads page:
http://punbb.org/downloads.php
That's also where Joey got his quote from, above.
There are 20 language packs out now, but Greek isn't one of them. So, as mentioned above, if you know Greek well enough and are willing to make the effort, open one of the language packs and translate from that, then send it to Rickard :)
The English language pack is inside the default PunBB download, under lang\en.
Can't you install a webserver at home and ...
The quick way: AppServ :D
How exactly would you include password hashes, avatar data etc. in that?
Did you notice the "extended" version I posted above? It began with:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:DC = "http://purl.org/dc/elements/1.1/"
xmlns:vCard = "http://www.w3.org/2001/vcard-rdf/3.0#" >
</rdf:RDF>Just swap the xmlns:DC for your own xmlns:PunBB and create your own RDF framework:
The Resource Description Framework (RDF) is a language for representing information about resources in the World Wide Web. This Primer is designed to provide the reader with the basic knowledge required to effectively use RDF. It introduces the basic concepts of RDF and describes its XML syntax. It describes how to define RDF vocabularies using the RDF Vocabulary Description Language, and gives an overview of some deployed RDF applications. It also describes the content and purpose of other RDF specification documents.
More about RDF: http://www.w3.org/RDF/
This seems to be an excellent book for our purposes: http://www.oreilly.com/catalog/pracrdf/
I was planning on having the actual avatar data in the XML though (base64 encoded).
It can do that too:
A number of vCard properties allow for inline binary values (encoded in BASE64) or external references via a URI. These include:
PHOTO
LOGO
SOUND
KEYIn the case of binary values, we can represent the property with a "vCard:ENCODING" attribute indicating the content value ("b"). For example:
<vCard:PHOTO vCard:ENCODING="b" vCard:TYPE="image/jpeg"> MSJD9s99DS(S@W99329(#9.... </vCard:PHOTO>In the case of an external reference, RDF provides a convenient encoding with the "rdf:resource" construct. For example:
<vCard:PHOTO vCard:TYPE="image/gif" rdf:resource="http://qqqfoo.com/me.gif"/>
I don't know about re-inventing the wheel like that, though. After all, isn't the point of this "interoperatability" and not just to import/export contact data?
How about using vCard as RDF, then extend that? Like the following example:
This example shows how an RDF vCard objects can be integrated with other metadata standards and encoded with RDF. In this example, the Dublin Core Metadata Element Set [DCMES] standard is used. (Please refer to [DCMES] for namespace and encoding recommendations.)
<?xml version="1.0"?> <rdf:RDF xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:DC = "http://purl.org/dc/elements/1.1/" xmlns:vCard = "http://www.w3.org/2001/vcard-rdf/3.0#" > <rdf:Description rdf:about = "http://qqqfoo.com/annual-report.html" > <DC:title> Annual Report 1999/2000 </DC:title> <DC:creator rdf:parseType="Resource"> <vCard:FN> Corky Crystal </vCard:FN> <vCard:N rdf:parseType="Resource"> <vCard:Family> Crystal </vCard:Family> <vCard:Given> Corky </vCard:Given> </vCard:N> <vCard:EMAIL rdf:parseType="Resource"> <rdf:value> corky@qqqfoo.com </rdf:value> <rdf:type rdf:resource="http://www.w3.org/2001/vcard-rdf/3.0#internet"/> </vCard:EMAIL> </DC:creator> <DC:date> 2000-10-01 </DC:date> <DC:subject> Company Report, Outcomes, Objectives </DC:subject> <DC:publisher> qqqfoo.com Pty Ltd </DC:publisher> <DC:rights> Copyright 2000 </DC:rights> </rdf:Description> </rdf:RDF>From: http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/
More about vCard: http://www.imc.org/pdi/
PHP vCard class: http://www.bitfolge.de/scripts/vcard.php
However, I see no reason why the structural stylesheet has to be common to all themes. I would prefer each theme to consist of two css files with links to both inserted by php. So the difference between our methods is that I stripped the default themes to their bare essentials, and used @import in each individual theme instead of touching the PHP?
The stylesheets would be called something like oxygen_main and oxygen_theme. If somebody wants to alter something structural then they can do it directly in the _main stylesheet rather than using the cascade to override it. How would they know to edit the main theme to make structural changes? Why not just override the structure completely by @importing another structure stylesheet?
It also makes it easier to distribute complete skins and/or make an online skin generator. Perhaps, but if you set a standardized name and format for the cascaded stylesheets, you could use either method.
If you use a common stylesheet and rely on the cascade then making wholesale changes to structure will involve overriding large parts of the common stylesheet. The end result could be a cosmetic stylesheet which is as big and complicated as the common stylesheet. But they don't have to. They can make their own seperate structure stylesheets and @import them too.
Of course you could make things really interesting by making both the structural and cosmetic stylesheets selectable by the user. This means you could have say four structural stylesheets and 6 colour schemes each of which work with all of the structural stylesheets. This gives you a total of 24 possible themes from 10 files. A bit more complicated I know but the real advantage is it would make it easy to produce specialist/accessability skins e.g. large fonts, fixed width etc.
Again, the only difference between our methods is that I haven't touched the PHP code, beyond a one-line change to hide "Common_" stylesheets from the style dropdown. If you wanted to modify the style selection that much, then it would be easy to replace the @import with direct PHP-provided link tags.
So we both agree encapsulation is a good thing, the only difference is our methods. But there is no difference -- if the PunBB style selection code changes, it's easy enough to keep up with the multiple required links. I'm simply saying that if PunBB is loading one CSS file, then from a CSS designer's point of view, @import is a useful and well-known CSS mechanism to encapsulate the structure and shared colour rules, where modifying the PHP code would be unfamiliar and unecessary.
There are no rules about @import, except inheritance. So what I did was load the Mountains.css file in the HTML through PunBB, then had Mountains.css load the Common_Light.css, which loaded Common_Framework.css automatically. If I wanted to load a different framework, there's nothing stopping me from creating my own Common_Custom_Framework.css and importing that from any theme I wish.
However, more important than encapsulation, in my opinion, are the actual selectors involved. Personally, I feel that there's very little structurally we can do with the current table layout. If there's a new, completely CSS-based layout coming, I'd love to have a sneak peak at it. If we do it right, we might even be able to create custom classes, so instead of doing:
TD.punhead,TD.punheadcent {color:#423F84}
TR.puncon1,TD.puncon1,TD.puncon1cent,TD.puncon1right,TEXTAREA {background:#E3E8FB}
TR.puncon2,TD.puncon2,TD.puncon2cent,INPUT,SELECT {background:#EDF0FC}
TD.puncon3 {color:#000;background:#D1DAF9}We could do:
.color1 {color:#423F84}
.color2 {background:#E3E8FB}
.color3 {background:#EDF0FC}
.color4 {color:#000;background:#D1DAF9}Then apply whatever colours we liked to parts of the page.
<table class="punmain color4">
<tr class="punhead color2">
<td class="punhead color3">
<h1 class="puntitle color1">PunBB.org Forums</h1>
</td>
</tr>
</table>This would make creating styles for mods much easier, just insert the proper colour classes and create a custom structural stylesheet if necessary.
Also, it makes figuring out what to change a lot easier -- just create a stylesheet which overlays numbers on a :hover, perhaps, and people can figure out what to change based on that.
For structure, I understand the need to use H1 and other direct tags, however for colour schemes, I find it unecessary.
Comments? :)
Actually, I don't think it will make it harder, I think it will make it easier.
By encapsulating the CSS it helps protect younger CSS authors from themselves. After all, if they add something to their template, it's a conscious decision -- they can't wonder where they went wrong, or why half the forums have suddenly shifted off screen, changed colour, or disappeared, because they can't accidentally edit the framework code.
If they make a mistake, it's much easier to experiment by erasing parts of your new stylesheet and let the previous inherited versions fill in what's missing. It's also easier to focus on what you have to change or edit now, when it's all you can see.
If you want to change the colours of a forum, which is easier to start customizing?
@import url("Common_Light.css");
TABLE.punmain {background:#00176A}
TR.punhead {background:#AFBCEA}
TD.punhead,TD.punheadcent {color:#423F84}
A:link,A:visited {color:#002195}
A:hover {color:#4C51B5}
A:link.punhot,A:visited.punhot {color:#8730D2}
A:hover.punhot {color:#2049E2}
TR.puncon1,TD.puncon1,TD.puncon1cent,TD.puncon1right,TEXTAREA {background:#E3E8FB}
TR.puncon2,TD.puncon2,TD.puncon2cent,INPUT,SELECT {background:#EDF0FC}
TD.puncon3 {color:#000;background:#D1DAF9}
TD,INPUT,SELECT,TEXTAREA {color:#122B84}BODY { background-color: #FFFFFF }
TD {
font: 10px Verdana, Arial, Helvetica, sans-serif;
color: #333333
}
INPUT, SELECT {
font: 10px Verdana, Arial, Helvetica, sans-serif;
color: #333333
}
TEXTAREA {
font: 10px Verdana, Arial, Helvetica, sans-serif;
color: #333333
}
FORM { margin: 0 }
PRE {
font-size: 11px;
margin: 0
}
TABLE.punmain {
border: none;
width: 100%;
background-color: #606060
}
TABLE.punplain {
border: none;
width: 100%
}
TABLE.punspacer {
border: none;
width: 100%
}
TR.punhead { background-color: #9AC55A }
TR.puncon1 { background-color: #DEDFDF }
TR.puncon2 { background-color: #EEEEEE }
TR.puncon3 { background-color: #C0C0C0 }
TR.puntopic { height: 1.5em }
TD.punhead { color: #FFFFFF }
TD.punheadcent {
color: #FFFFFF;
text-align: center
}
TD.puncon1 { background-color: #DEDFDF }
TD.puncon1cent {
background-color: #DEDFDF;
text-align: center
}
TD.puncon1right {
background-color: #DEDFDF;
text-align: right
}
TD.puncon2 { background-color: #EEEEEE }
TD.puncon2cent {
background-color: #EEEEEE;
text-align: center
}
TD.puncon3 { background-color: #C8C8C8 }
TD.puncent { text-align: center }
TD.punright { text-align: right }
TD.puntop { vertical-align: top }
TD.puntopright {
text-align: right;
vertical-align: top
}
TD.punquote {
background-color: #F6F6F6;
border: #606060;
border-style: dashed;
border-width: 1px
}
A:link, A:visited {
text-decoration: none;
color: #415720
}
A:link.punhot, A:visited.punhot { color: #C03000 }
A:link.punclosed, A:visited.punclosed { color: #888888 }
A:hover {
text-decoration: none;
color: #709735
}
A:hover.punhot { color: #F43E00 }
A:hover.punclosed { color: #AAAAAA }
IMG.punavatar {
margin-top: 3px;
margin-bottom: 3px
}
.puntext { font-size: 11px }
.punedited {
font-size: 10px;
font-style: italic;
}
.punsignature { font-size: 10px }
.punheadline {
font-size: 12px;
font-weight: bold;
}
.puntitle {
font-size: 14px;
font-weight: bold
}
.punhot { color: #C03000 }Mmm. Maybe I'll look into how others have handled time zones and daylight saving time, I know vBulletin keeps track of it somehow.
What did you think of my profile.php form suggestion? ;)
PunBB Forums → Posts by Louis
Powered by PunBB, supported by Informer Technologies, Inc.