[Logos]

Originally Posted by AshDigg

Persistent connections were removed from the code a little over a month ago, and will not be in the next release.

Thank you for confirming that. I assume that the latest stable release you have available for download does not contain this fix? Because that is what I downloaded and it is using PC by default.

[kbeeveer46]

Pligg 9.1 which is the latest release uses persistent connections. The latest testing code does not, that's why I wanted to see if you could test it and see how it compares to your 9.1 tests.

[Logos]

This test version is much better, less some minor aesthetic issues, but it's a testing version so that's ok.

I see that you are not using the ezSQL caching system, and I went ahead and enabled it on my install. It appears to load faster, but I would have to enable a timer to see for sure.

Anyways, if you want to test it out, simply add the following lines to the end of the config.php file:

$db->cache_timeout 	= .25;
$db->cache_queries 	= true;
$db->use_disk_cache 	= true;
$db->cache_dir 		= '/home/username/public_html/cache';

The timeout is set at 15 minutes, you can reduce it easy enough:

1 	= 1 hour
.75 	= 45 minutes
.5 	= 30 minutes
.25 	= 15 minutes
.16 	= 10 minutes
.08 	= 5 minutes

It really depends on how you want it setup. I have no problem with a 15 minute cache because I use the site amongst developer/designer friends to share links. But if you wanted to enable it, there you go.

You will need to change the $db->cache_dir accordingly, the way I posted it above is the default path for most hosts, just replace the username with yours.

And just a note, I would move the cache directory below your public_html directory so people cannot access it.

I'm not exactly sure what information you guys store in the cache directories, but they could have potential for exploitation.

[dollars5]

Thanks Logos for testing for us. And very much for sharing the db caching config.

I have one doubt - is that config.php the one that is used by Pligg under the Pligg-base-folder; that requires these additions?

[Logos]

Yes, this is for the config.php file in the root directory of the installation, not in a sub-folder.

To me, this was the most logical place to put this. Although, I have to admit, the organization of the files for Pligg is really, well, a mess to say the least.

It would, to me, make more sense to use the init.php file as a place to load all of your required/included files, and to setup instances of classes.

For example, typically sites I develop, I have in the includes directory a file called init.php which has something like this:

<?
init::req(ABSPATH.INC.'core.php');
init::req(ABSPATH.INC.'mysql.php');
init::req(ABSPATH.INC.'template.php');
init::req(ABSPATH.INC.'functions.php');
init::req(ABSPATH.INC.'navigation.php');
init::req(ABSPATH.INC.'formatting.php');
init::req(ABSPATH.INC.'validatation.php');

$do = new validate();

$db = new mydb(DB_HOST, DB_USER, DB_PASS, DB_NAME);

$db->cache_timeout 	= 24;
$db->cache_queries 	= true;
$db->use_disk_cache 	= true;
$db->debug_all 		= false;
$db->cache_dir 		= ABSPATH.'cache';

class init {		
	function inc($file) {
		include($file);
	}
	
	function req($file) {
		require($file);
	}
}
?>

The only files before this that are calling are config.php and settings.php, which basically setup definitions and clear out PHP_SELF, globals, POST, GET, etc. for security reasons:

<?
define('DB_HOST', 'localhost');
define('DB_USER', 'dbuser');
define('DB_PASS', 'dbpass');
define('DB_NAME', 'dbname');

define('ABSPATH', dirname(__FILE__).'/');
define('INC', 'includes/');
define('TEMPLATES', 'templates/');
define('THEME', 'default/');

require_once(ABSPATH.'settings.php');
?>

...

<?
require(ABSPATH.INC.'init.php');

unregister_globals();

$PHP_SELF = $_SERVER['PHP_SELF'];

if(empty($PHP_SELF)) {
	$_SERVER['PHP_SELF'] = $PHP_SELF = preg_replace("/(\?.*)?$/", '', $_SERVER['REQUEST_URI']);
}

if(get_magic_quotes_gpc()) {
	$_GET 	 = stripslashes_deep($_GET);
	$_POST 	 = stripslashes_deep($_POST);
	$_COOKIE = stripslashes_deep($_COOKIE);
}

$_GET 	 = add_magic_quotes($_GET);
$_POST 	 = add_magic_quotes($_POST);
$_COOKIE = add_magic_quotes($_COOKIE);
$_SERVER = add_magic_quotes($_SERVER);

function unregister_globals() {
	if(!ini_get('register_globals')) {
		return;
	}

	if(isset($_REQUEST['GLOBALS'])) {
		die('GLOBALS overwrite attempt detected');
	}
	
	$no_unset = array('GLOBALS', '_GET', '_POST', '_COOKIE', '_REQUEST', '_SERVER', '_ENV', '_FILES');
	
	$input = array_merge($_GET, $_POST, $_COOKIE, $_SERVER, $_ENV, $_FILES, isset($_SESSION) && is_array($_SESSION) ? $_SESSION : array());
	
	foreach($input as $k => $v) {
		if(!in_array($k, $no_unset) && isset($GLOBALS[$k])) {
			unset($GLOBALS[$k]);
		}
	}
}
?>

I take the WordPress approach to things. The index.php file has one line, an include to the config.php file. That file has an include to settings.php, and that file calls the init.php which calls everything you need.

The template.php file in the init.php file is the one that loads all the template, and I use a rewrite class for handling all the templates to create the "file structure" that the user sees but doesn't really exist.

I then take cues from vBulletin, and load a lot of language, phrase, etc., variables into an array for making quick when it comes to calling certain things that are re-used a lot and are not dynamic (like phrases and templates), which are stored in a table in the DB as well.

I don't know, that's a programmer's thing though, like I hate when people name variables in a way that I do not (for example, $mybigstring verses $my_big_string verses $MyBigString...I prefer the middle one, it's easiest to type and read).

The organization however, of Pligg is just all over the place. I would have a phrases, phrases_groups table to organize the entire language structure. Too many things to name I guess, but no point in ranting, it's y'alls project

[Logos]

Also, I was pulling server stats the entire time, and this version is much better than the public release. The load didn't spike, the connections dropped quickly (thank you for removing persistent), and it was overall great. No issues whatsover from someone who runs a hosting company. The public version, however, I would not allow.

The load goes up a tiny bit, but that's mainly because of the amount of information that is loaded. I wish you guys had a way to completely disable the AJAX features. Take a look at how vBulletin gives you this option. I would study their backend really well, their configuration settings are a dream, and it would be nice to drop the SMARTY template system (to me, just seems like more bloat to add when you could use your own template system).

Nonetheless, great program overall, just needs some work (but hey, that's what opensource is for ).