I don't know what this could be really - it might be worth checking that you've covered all the points in the ReadMe file. It sounds like there are some parts wrong somewhere. It may be easier to 'begin installing the mod again'.

I didn't delve a great deal into the PunBB code, I only glanced upon what was needed to get the poll working. Charmool (& later dEmon) did most of the work on this and would have a better idea.

(also it's late and I'm tired big_smile ).

I've tested. But i guess thats not exactly what you meant lol

If you want to test it safety and know you can go back to what was there before, simply make a backup of your database so you can revert back to the old ones at the drop of a hat.  Or of course, you could create a seperate instance of PunBB and install the mod to that - a test enviroment basically.

Just confirmation for those that are interested. This works fine on version 1.2.2 as well. Below is what I did to get the Poll to work on the board I am working on. This isn't a "do this and it will work" post, but it's a "try this and maybe you will be as lucky as me"!

Summary of Install
- Downloaded Charmool's original version of the software.

- Downloaded dEmon's update.

- Edit the install_mod.php and add '1.2.2' to the array at the top. (Line 12 should read:)
     $punbb_versions    = array('1.2' ,'1.2.1','1.2.2');

- Follow the instructions installing dEmon's version as per the Readme.

- The dEmon version is missing the language file as noted earlier in the thread. This is simple to fix though. It's available in the Charmool version (though it needs renaming).
    *- Charmools is in : /lang/en/en_poll.php
    *- you need to move it and rename it to:   /lang/English/poll.php

- In addition to dEmon's instructions in the readme (you'll notice one of the latter instructions is repeated twice), you'll need to edit one of the lines you pasted into edit.php:
   require $pun_root.'include/punpoll/edit_save.php';
should be:
   require PUN_ROOT.'include/punpoll/edit_save.php';

Similiarly, the same problem exists in post.php
   require $pun_root.'include/punpoll/post_save.php';
should be
   require PUN_ROOT.'include/punpoll/post_save.php';

- This step I didn't see mentioned recently, but it's worth navigating to your /cache directory and deleting all the files except index.html and .htaccess. This stage basically makes sure all the config changes take affect and you don't get the "undefined index o_polls" errors & so on.

The above isn't a complete guide and I may have missed something out, but it certainly seems good to me.


edit: I haven't received the error notices regarding "question" & "answer" indexes that some people have had, so fixes especially for those have not been included in my above text.

4

(3 replies, posted in PunBB 1.2 troubleshooting)

Sorry for my slow reply - I was not around yesterday.
There is no entries in the log for the access or errors at all... sad

edit: well - there are, but not referencing the time that it dies.

5

(3 replies, posted in PunBB 1.2 troubleshooting)

Hi,
I'm having a few issues with PunBB, or more specifically, my altered version. I'm currently trying to install PunBB on a Solaris Box with PHP Version 4.0.6.... The minimum version for PunBB is 4.1.0. I'm told that there is no easy way to update the Solaris box without considerable downtime (or they don't want to wink ) - so I'm left with 2 alternatives: Alter PunBB to be 4.0.6 compliant, or don't use PunBB.

Well, I like PunBB. It's perfect for the job (unusually, the word perfect in this situation isn't far from the truth) - so I wanted to try the downgrade. I first went about replacing all those pesky $_SERVER, $_POST globals etc. with their $HTTP_*_VARS counterparts. These occasionally required globalising. I also had to alter the install script to remove the version check which was only available in 4.1.0 anyway (I saw the other post about this and it made me laugh! proves your still human Rickard!).

I then had problems with the forums working up until certain points and then I would get "page cannot be displayed" errors - not PHP warnings, notices, errors etc (which definately would be the normal scenario). I traced these down, after quite a bit of time to be caused by array_map and unbuffered mysql queries. (much time would probably have been saved had I used the php changelog to see the diffs between 4.0.6 and 4.1.0.... but my brain clearly wasn't on that path unfortunately. I look now and it warns me in 4.1 that array_map and unbuffered queries cause PHP to crash - which must be why it's a page cannot be displayed and not normal php errors.

Anyway, all these are fixed now and I can't cause the forums to crash.... except I can.... but only by using it quite a bit. There appears to now be only one bug, but this bug is inconsistant from what I can guess at present. I can use the forums as normal, post, reply, view the admin, change settings, but then I'll hit a page, e.g. The "userlist" and the register.php have caused it to die a "page cannot be displayed" death. However, if i click refresh (resend data if needed) - no problems.... Try it again. no problems, go back, try the same route again, no problems...

Basically - I have no idea how to replicate the error (page-cannot-be-displayed) except to use it quite a bit and hope (!!) it dies.

I know this isn't a supported topic as to my modifications, but I'm just appealing for help basically and seeing if anyone has had similar problems in the past? Specifically - does anyone have this running on php with a version of 4.1.0 exactly? If so, then my presumptions will be that it was definately a change between 4.0.6 and 4.1.0 thats causing my heartache.

Thanks in advance for any pointers, help etc anyone can throw my way!

p.s. $unbuffered always = false in my code now, so it never runs an unbuffered query. and Array_map has been replaced in all instances with a for each statement that does the same task.

Yep, it would seem this is the default for Core 3 release - not sure (though I'm lead to believe not) for previous versions.

This isn't really a problem anymore (I've solved it as far as i'm concerned) - but I'm hoping I can save someone else the hassle. (if they are equally as new to linux as me).
I installed a fresh version of Fedora Core 3 and got running everything needed for PunBB. I installed it, it created the databases and finished everything happily. Got to the "create the config.php" file screen of install and it told me "cache" and "img/avatars" were not writeable & that I should chmod 0777 them if I was struggling. Makes perfect sense.... Except ... it didn't work...

I then tried many many extreme idea's before deciding start taking some @'s of the code it was failing on in the PHP to get the error messages actually being given by PHP. Got these error messages and it was clearly saying it STILL didn't have permissions (by this time everything is owned by the apache user and 777'd). I started to get frustrated till I finally found the little devil.

SELinux is enabled.... simply disable it to allow PHP to write to directories outside of /tmp
(or of course - you could alter some of the settings maybe? I never tried this as the box I'm working on is a development box and won't be used as live).

Problem solved.

Again - probably something someone even slightly more linux trained than a goldfish-on-the-dole could have spotted.... But I'm not that goldfish sadly and it took me a while.

8

(17 replies, posted in PunBB 1.2 troubleshooting)

The situation isn't always as simple as freedom of speech.
I'm myself looking for something along the lines of this rather desperately because I'm in a position where I have been asked to create a forum where, if the public were able to post anything, I would be putting my job on the line.

It's not a case of "this person is being mean to someone", but it's a case of website links and similar.

Posted my reply so I can listen for replies also wink (and the subscribe link was further from my mouse pointer and i'm lazy).