Search options (Page 11 of 19)

Do you mean this?:
http://www.punres.org/desc.php?pid=274

Just some thoughts on this:
(1) Indeed. It's a very primitive way of doing things. Tedious, risky, in-elegant. Very un-2007.
(2) and (3) and (4): The way I work through these issues is:

(a) even with my limited knowledge of PHP, I try and thoroughly understand what each new mod or patch is trying to do. Worryingly, you often don't have to know much to see that some punbb mods have significant problems that you can often catch before their code goes into your forum
(b) I thoroughly document every mod and code alteration that I make so I know what I did to what page and when, which mod modified the database  etc;
(c) I maintain a 'dev' punBB which I build any mods, security patches or tweaks into first, with all the 'reveal queries' config switches on, and then if they test out and work OK with the existing code, they then go into my production punBB codebase;
(d) I never use automated patchers or diff toools. I manually apply all updates using tools like WinMerge. Things will be guaranteed to break otherwise, and it gives me the chance to eyeball every proposed update.

As to (5) - good question. At least I am pretty confident that I know all of the mods and alterations I have done, so I expect that will help in stepping across (carefully) to 1.3.

As to VB - in some ways it faces the same problems as punBB here. If you make any hacks to it or apply non official VB mods/themes, you'd face may of the same issues in keeping it all working across VB version upgrades.

I guess where VB and other more fully featured forums save you some hassle though is that they have most of the features built-in that may punBB users have to rely on mods and hacks to achieve.

I use WinMerge - http://winmerge.org - to find and help me review any file or code changes. I unzip the latest punBB version into a folder, then use WinMerge to find the changes between the current version of punBB and the latest, and then make any necessary updates.

This process can be a bit tedious, inevitably, but it works for me.

I also have a few mods installed and other code tweaks that need to be worked around, so any automated update will likely break things.

Connection limits to MySQL are under the hosts control. Unless you have access your self to editing MySQL's configuration, specifically the entry below:

# The maximum amount of concurrent sessions the MySQL server will
# allow. One of these connections will be reserved for a user with
# SUPER privileges to allow the administrator to login even if the
# connection limit has been reached.
max_connections=255

HOWEVER it may not be all up to your host

You may be able to cut down on the number of connections your board generates by looking at the plugins you have loaded and also the options you have turned on on your forum.

I'd start by turning on via the setting in /include/common.php

// Enable DEBUG mode by removing // from the following line
define('PUN_DEBUG', 1);

to see how many queries each of your page views is generating.

Without registering to see your forums, it is possible that you may have installed plugins that are spawning excessive MySQL queries. This is certainly not unheard of - eg in the case of the various sub-forum mods, which are very inefficient and spawn *large* numbers of MySQL connections per page view.

Even some of the standard punBB features like the 'Users online' option that shows all the users currently online generate an extra MySQL load per page view. Perhaps you could review your use of some of those extra punBB options.

By optimizing how many queries your pages spawn per user page view, you may be able to cut down the number of simultaneous connections MySQL wants to open, and operate within the current limits set by your host to your usage of MySQL.

See the simple code to do this at:

http://www.punres.org/viewtopic.php?pid=13645

Sounds like something a lot of people will find useful, myself included

A couple of questions:

Do you have a feature list?
What's your timetable for it to be available?

Nice style. Polished, inviting, classy.

At 25 paragraphs long, I think it can also confidently claim the title of 'PunBB Site With the Most Rules'.

http://www.bonjovi.it/forum/misc.php?action=rules

http://www.typolight.org/forum/

Nice CMS. Has a bridge <> punBB too, apparently.

Very nicely styled.

Maybe I am confused.

What I am suggesting is that the pages that display the AdSense have to be the one that are read by the Googlebot.
Eg if you have a bunch of AdSense ads on /viewforum.php, then that page needs to be accessible to the Googlebot directly.

By blocking in robots.txt the Googlebot from accessing the 'normal' pages which the AdSense displays on, won't the AdSense die?

I mean the pages with the ads on them will still remotely load the jscript off google.com, naturally, but without the pages that host the AdSense being spidered, google won't know what ads would be correct to show on those pages.

The rewritten html sitemap pages may be successfully spidered, but you are then kind of saying to the googlebot: hey buddy, spider these (rewritten) pages over here, and then use the results of that to figure out what ads should be displayed on those (dynamic) pages in that pile over there, which you aren't allowed to see....

A good discussion of similar issue and solution is here:

http://www.aprelium.com/forum/viewtopic.php?t=10796 on the web site of the people who make the very nice Aprelium web server.

The issue is either that your php.ini config doesn't have 'allow_url_fopen = on' set.

Or (more likely) that you are trying to call the included URL via a http:/etc etc call, like

include("http://yourwebsite/extern.php?action=new&show=10");

Try it as just a file path link instead - eg include("/extern.php?action=new&show=10");

Even if the Zend Accelerator is installed, it may not be configured optimally. If it is already installed, the simplest option for your is to just make sure it is setup correctly for you and working as best as it can.

Alternatively, setup a test punbb somewhere, install an alternative cache like xcache, and see if it works for you, and then install that on your live site.

But identifying whether the Zend Accelerator is already there is important. Your life may get complicated if you have two caches fighting each other on the one server - they will negate each other.

Aside from caching, your users will also see a performance boost if you enable Gzip page compression within punBB or via whichever cache you go with. I notice that you don't seem to currently have that enabled. That might also be something to look at too.

I'd also certainly look at all of the mods you have installed - the sub-forums, the RSS/Atom feeds etc.

Do they need to be where they are on every page? Can the same task be done simpler somehow, perhaps with a different mod? Is the PHP code of these mods doing stuff 'under the hood' that you don't need? (and which you might therefore be able to cut or comment out of their code...). Etc

Site performance tuning is something you will probably find yourself doing every day on a big board. It's one of the down-sides of your success