1

(29 replies, posted in PunBB 1.3 troubleshooting)

The arrow is one of those situations where a 50% transparent black and 50% transparent white 24bit png would be super useful. Too bad...

2

(12 replies, posted in PunBB 1.3 troubleshooting)

guardian34 wrote:

You can also write code in the PunBB files themselves, and then cut/paste into an XML file (or make/use a script that will accomplished the same thing).

That appears to be exactly what PunXS does.

3

(12 replies, posted in PunBB 1.3 troubleshooting)

What's the setup like for using PunXS? I recall seeing something a loong time ago, but I don't have any more info.

How does development of extensions work?

I mean, if it's in XML files, how does an author edit, overwrite, test new code, and continue on?
Does the extension have to be uninstalled & installed each time a change is made?
When there is an error in the script, does it give the line number of the eval error? Or just where the code was eval'ed?

I'm trying really hard to not prejudge having the code in XML files which get database loaded, my brain just sees a lot of troublesome issues around it that have all probably already been dealt with.

(I know the full docs about extensions are coming, but since the post asked us to play around with the system, some intro would be helpful. smile)

5

(29 replies, posted in PunBB 1.3 troubleshooting)

elbekko wrote:

Face it, people copy and paste things. They couldn't give less of a rat's ass if it contains an ID.

By that same merit there's no reason to have SEF at all.

6

(29 replies, posted in PunBB 1.3 troubleshooting)

Rickard wrote:
chuyskywalker wrote:

Sorry, I was unclear. I'd like the folder option + fancy - type_numerals. If you check out the fancy option, it still uses the "forum1-Test-Forum" syntax. The "forum1" should be dropped, there are easy ways to get around doing that which several other software solutions successfully employ.

I'd love to hear your suggestion for getting around this. The only solution I am aware of is storing a safe URL version (a stub) of the forum and topic titles and then doing a SQL string search for the stub in the respective tables. Not very efficient.

To make things worse, you have to deal with duplicates. You also need to keep URLs permanent, which means storing the old URL stub for forum and topic titles whenever someone changes a title.

That's the way that Wordpress works it. Seems to work out pretty well, but it does have that very, very nasty side effect of stub changing 404'ed content.

The simple solution, at least for forum|topic 's would be to setup a table like so:

| stub_id | type | stub | id |  ( primary on stub_id & unique on type,stub )

And anytime a forum/topic is updated, generate a new stub for it. At activation/change, a mass update would need to be done (eek, I know.) Always grab the most recent stub_id when showing urls. This way you can keep the old ones working and keep the old references still working.

The generation process, when hitting duplicates isn't pretty, as one might assume. Usually it simply entails trying to append "-N" to the stub until N++ no longer is a duplicate. Not the best, but a reasonable option, imo.

And your other point about having to do a query against the database to grab the matching ID is true -- but even in a hugely busy site, I would take that trade off.

I suppose my main point boils down to this: Search Engines don't care about ? url's anymore. They haven't for several years now. Friendly URLs are only useful to give people context when looking at links, and the current "SEF" schemes aren't any more people friendly than what was previously available through "?id=N". The fancy set, being the exception, is a step in the right direction, but doesn't really do the trick because we're still stuck with the non-human relevant information.

Perhaps I'm just being too picky, but I think this can be better.


----

While on the subject, I was testing to see if having the URL's for one method would still work when another SEF method was active. IE: What happens when I use both these links?

- http://127.0.0.1/pun/forum1.html
- http://127.0.0.1/pun/forum/1/

Turns out pun happily 200's me on both of them. This is bad mojo in SEO. It's duplicate content under different URL schemes. To "the googles" it is supposed to mean that the person is trying to push content for more relevancy or hits. If possible, it would be good to 301 people to the "official" variant of a URL.

Paul wrote:

I also tested the arrow entity and decided against because somewhere a box showed up instead. I can't remember which browser though. Don't pay much attention to any graphics. The stylesheet really is unpolished and that includes any graphics used.

I kinda figured that was the reason. Same reason I originally said a different graphic would be appropriate.

7

(29 replies, posted in PunBB 1.3 troubleshooting)

Jérémie wrote:
elbekko wrote:

I'd actually prefer something like this for the arrow:

U+279C     ?     Heavy round-tipped rightward arrow

If UTF-8 is in anyway, why not use it? smile

Is it included in most (really MOST) default font used by OS&UA?

http://jrm.cc/extras/rarr.html ? works pretty well too. Seems to have the right coverage. However, it would have to be included as a text element in the breadcrumb which probably doesn't fly consider the text output actually reads like this:

No CSS Text wrote:

Back to: PunTest - Back to: Administration - You are here: Install extensions

The goal of which, I imagine, was to make nice for screen readers.

8

(29 replies, posted in PunBB 1.3 troubleshooting)

Jérémie wrote:
chuyskywalker wrote:

- "URL Scheme" needs waaaay more details -- what are the various schemes mean? A few examples of the resulting URLs would really help

On the other hand, it's quite easy to try one, then another, one, etc. Just one click.

Users shouldn't be made to do extra work when we can provide simple examples. The admin interface uses help elements all over the place as is, so it's certainly not faux-paux to do so.

Jérémie wrote:

- SEF Folder should use "safe" html names in the URL instead of numbers. IMO, /forum/1 is not much more useful than /forum.php?id=1 -- neither tells a user much of anything about the url. Search Engines don't much give a rats tookass about ?id=NNN anymore so that point isn't valid any longer -- it's all about user experience with "SEF"'s. Silly name for them these days.

This is in: try the "fancy" setting.

Sorry, I was unclear. I'd like the folder option + fancy - type_numerals. If you check out the fancy option, it still uses the "forum1-Test-Forum" syntax. The "forum1" should be dropped, there are easy ways to get around doing that which several other software solutions successfully employ.

Jérémie wrote:

- if you set the SEF url's to on, and .htaccess isn't working right, it's very difficult to get it turned back off (going to the non-sef url version of the options page has you trying to submit the new option changes to the SEF url which fails.) Need some kind of "Bail me out of SEF" button

The fastest way is to have the crude-url version of that page bookmarked. But maybe a link/button would be easier, yup.

Getting to the crude-url version of the page isn't the problem -- having it do anything is. When you have SEF on, and you load the crude-url version of that page, the form action value uses the SEF variant of the page url. Since SEF isn't working, this means that trying to submit fails and you can't reset the option.

Jérémie wrote:

- "Allow new users to register. Disable only under special circumstances." I'll disable that whenever I dang well please. I suggest removing this "warning".

You are not everyone. The English is very, very slightly, rude, but other than that it's a safe warning for newbies.

I don't see this needing any special warning, is what I'm getting at. There can't possibly be any question about what this option does and what it means to disable it. I think it's simply excessive.

Jérémie wrote:

- "Allow registration with banned e-mail addresses." why this is allowed by default, I do not know. If shouldn't be.

Yes it should. If one is banned, and get a "this email is banned" error, one will simply enter another dummy (hotmail or whatever) email address. While with this, at least the admin can catch up on the dumb banned.

This is the wrong way to fix that particular problem. When a user signs up with a banned email or IP address, they should not be told what the problem was, but simply that they aren't allowed to register. Anything else is giving the maligned user too much information.

It's like having this kind of error on your login form: "Sorry, the password for joe@joe.com was incorrect". It tells the user too much compared to "That username/password combination failed."

I think the default action here is actually very, very confusing to new admins. Think about it: they ban a user, IP, and email and then that same user comes back with the email again. The admin is left sitting there going, "How the heck did they do that? I banned that email!" cursing the seemingly broken email ban.

I stand by my assertion that this should be off by default so that banned emails are not allowed back in -- however, if it stays like this then it definitely needs to propagate to the banning page with a note next to the email box that "* Email addresses can currently be reused for signups." with a link to the option page to toggle that back

9

(29 replies, posted in PunBB 1.3 troubleshooting)

- install.php doesn't have the password fields set to type=password

- on the "login screen, I dislike the "forgotten" stuff being above the login boxes -- it's like assuming I'm dumb

- the breadcrumb on the admin pages seems redudant considering the nice menu's you've setup

- source order -- I highly value the work that the devs do on Pun, but don't put the credit link in the header

-

WARNING! If you select any scheme other than the default scheme you must copy/upload the file .htaccess from the extras directory into the forum root directory. The server that hosts the forums must be configured with mod_rewrite support and must allow the use of .htaccess files. For servers other than Apache, please refer to your servers documentation.

Do a test to see if you can write the .htaccess file and do it if you can -- don't scare the poor user if you have make their life "click to turn on" simple

- "URL Scheme" needs waaaay more details -- what are the various schemes mean? A few examples of the resulting URLs would really help

- in rewrite.php "header('HTTP/1.x 404 Not Found');" "1.x"? Is that ok?

- if you set the SEF url's to on, and .htaccess isn't working right, it's very difficult to get it turned back off (going to the non-sef url version of the options page has you trying to submit the new option changes to the SEF url which fails.) Need some kind of "Bail me out of SEF" button

- with the included SEF .htaccess, apache fails to recirect correctly on a windows XAMPP install when in a subdirectory. Gives the error [Wed Jan 30 23:54:39 2008] [error] [client 127.0.0.1] script 'F:/xampp/htdocs/rewrite.php' not found or unable to stat, referer: http://127.0.0.1/pun/ adding /pun before /rewrite.php fixes this. Not sure if there's a proper fix though.

- SEF Folder should use "safe" html names in the URL instead of numbers. IMO, /forum/1 is not much more useful than /forum.php?id=1 -- neither tells a user much of anything about the url. Search Engines don't much give a rats tookass about ?id=NNN anymore so that point isn't valid any longer -- it's all about user experience with "SEF"'s. Silly name for them these days.

- Announcement Setting: in a real forum situation, the announce gets used A LOT -- having it buried under so much navigation and scrolling is really troublesome -- it should be pulled out and easier to work with

- "Allow new users to register. Disable only under special circumstances." I'll disable that whenever I dang well please. I suggest removing this "warning".

- "Allow registration with banned e-mail addresses." why this is allowed by default, I do not know. If shouldn't be.

- On the censoring page, if censoring is turned off, perhaps there should be a note to that effect.

- "Maintenance Mode Logout Warning" -- why not write into logout.php a quick check on "if maintenance mode is on, don't allow admin to logout" Would solve the whole issue.

- On the admin pages you tell the user which page they are on in four separate places -- title, bread crumb, highlighted menu/submen, and the {PLACE} text. Overkill in my opinion

- The arrow between pages doesn't graphically make sense -- probably because it's the only non-text item on the page and it's got shading. I'd reduce it so a very simple, flat arrow that looks like text, ie: http://www.cw-chamber.co.uk/images/small_arrow.gif

----------------

That's my 30 minute admin exploration -- I'm looking to dive into extensions later ;D

10

(125 replies, posted in News)

Better get on it, others are looking pretty slick ;D

p.s. Rickard, I'm now living in Stockholm. Perhaps sometime when later when going outside doesn't cause hypothermia we'll pass ways smile

Moo hahaha!

But seriously, I made a plugin for pun which put a whole load of moderator controls into a single panel So, for example, a mod can add a reply, close a post, and pm the user all in one fell "Submit" action, but to do that I had to reduplicate all the PM, posting, and closing code in my extension. Kinda sucks.

Must learn to search. Whadda noob:

- http://punbb.org/forums/viewtopic.php?id=16363
- http://dev.punbb.org/ticket/50

Even still, the inherent difficulty of this is quite daunting.

I'm toying around on the 1.3 code base and hitting a brick wall. Let me example:

I'm looking at profile.php. Pretty simple, no? Anyway, I read through the section about deleting a user. Seems pretty cool. But then it hits me -- when I'm writing extensions, how does my extension gain that power?

Let's say I want to make an extension that, if a person includes the word "noob" in their first post they are automatically deleted with a vengeance. At the current time, I have no choice but to (shudder) duplicate the "delete user" code into my extension. This is, pretty much, nasty. If there are bugs with it, my extension will likely get left in the dust and exposed when updates happen. Code duplication like that, in general, sucks.

So I said, "Fine, I'm a smart guy, I'll just put all these little utility events in functions and make a new file, 'api.php' to serve me well." This is where the pretty red&gray brick wall landed in my face.

See, making the move from that file into a function does something. Something very special -- it changes the variable scope of what you have access too. When running en situ for profile.php works fine, if you try putting the delete user ability into a function, suddenly it's missing the database. Then another variable. Oh and that one you missed too. In short, PunBB very heavily relies on the idea that every variable is always available regardless of scope for some very important tasks.

I think the practicality of moving the majority of this code to an internal API-type setup would be essential to a proper extension platform. Extension authors will NEED functions like "delete_user" or "ban_user" -- even things as broad as "add_post" or "add_topic" should be in the API for extension developers to take advantage of.

Hooks are great (need a LOT more based on what I'm seeing in SVN, but I'm sure the devs know that) but without some kind of global utility API, we're either stuck duplicating code or up the creek with no paddle. Neither  option is pretty.

Like I said, none of them really. They are all so haphassardly hacked in that separating them from the base code would be nigh impossible.

Should 1.3 included a more manageable plugin architecture (See WordPress for the best example I've seen to date) then I'll package up things and release them.

I'm also working on a patch that adds unlimited sub-categories with no more over head than the current system. Oh it's sweet.

Sure is. Not super complex, eh? big_smile

lol

I probably won't release much of what I've done simply due to the "hack" nature in which i've made it. None of it would probably work with anything other than MySQL, and I don't think I could make a decent 'diff' file out of it either (because of all the other hacks I've made).

I'm hoping that 1.3 will have a much nicer plugin architecture that will allow plugins in/out alot more seamlessly, then you're likely to see some of my things released.

18

(6 replies, posted in PunBB 1.2 show off)

Looks good -- get those moderator lists to wrap along the rest of the text edge though wink

I thought I might post some of the mods I made to the BF2S forums. They're pretty nifty, but I don't think I can release them simply because of how mangled up they are big_smile click them for their full version, since I think the forum will shrink them all ugly up wink

Deleted Threads and Posts
I was tired of not KNOWING what had been deleted by my mods. People were making accusations of abusive of powers and such, so I wanted to track it. To do so I added a column in the topics and posts tables called 'deleted' which is 0|1. Modding all the "SELECT" statements based on $is_admmod was the tough part, but the results kick ass:

Threads:
http://images.bf2s.com/forum-features/deleted-threads.gif

Posts:
http://images.bf2s.com/forum-features/deleted-post.gif


Edit History
In addition to loosing posts and threads, I wanted to track edit histories so I could see what both users and mods were doing to posts. This has actually come in handy a few times.

History Link:
http://images.bf2s.com/forum-features/history.gif

History View:
http://images.bf2s.com/forum-features/history-2.gif
(not pretty, but it's only for admins/mods anyway.


Merge Thread
One of the more annoying things lacking from punbb is anyway to merge threads. So I stepped up to the plate and put together the script for doing so. I'm not familiar enough with pun to say that I did it right (search indexes, etc) and it's integrated with my 'deleted=1' method of deleteing, so it's not portable. The point is that it's possible -- in fact, it's not even that much code wink

Selection:
http://images.bf2s.com/forum-features/merge-1.gif

Merge Intro:
http://images.bf2s.com/forum-features/merge-2.gif

Merge Select Target:
http://images.bf2s.com/forum-features/merge-3.gif
This is a lot more fun to actually see since it's a neat little ajax piece of refreshing fun big_smile

Merge Confirm:
http://images.bf2s.com/forum-features/merge-4.gif


I'd be happy to give out my files, but I honestly don't know how much use they'll be. I'd worry about security holes, implementation boo-boo's and just generally not working. That percaution said, let me know if you're interested.

Rickard wrote:

Nice! Me big_smile

Got some catching up to do wink I guess it would be rather redudant to say I think pun is nice, considering I use it. Kinda tough to modify, but simple and CSS/XHTML make up for it wink