BUCKHORN

If I understand this correctly, I think I would choose the third method. This should be in the head section of your html, then then the template structure doesn't matter. I would imagine you can save the css in the module folder and pass the full path/to/module/css/style.css to $config->scripts->unique. Using this method does raise some questions, I'm pretty new to PW and don't know how it works yet. How are dependancies handled? How are duplicate files handled?

I do agree, if you have Apache and the technical know how to pull this off, then using Apache is the best method, because it will compress your css, js and other files (though you can compress js/css using php). The only problem with this approach is we are making the assumption that Apache is the only web server in existence and that users have the ability to enable and configure the Apache modules that are required to pull this off. Also, in many cases, these types of configurations should go into the vhost.conf for performance reasons. Vhost.conf will be read once when Apache restarts vs. .htaccess which will be read on each and every page request. The second part of the conversation is more interesting to me though. Will saving compressed data in the form of cache files be faster than saving uncompressed data? This is where I can see some potential value for using compression with PW. $compressed_cache = gzencode($data); // if you need to serialize use gzencode(serialize($data)) // for zlib compression use gzcompress($data) The when you are retrieving the cache file you can uncompress it... $value = gzdecode(file_get_contents()); // if you need to unserialize use unserialize(gzencode(file_get_contents())) // for zlib compression use gzuncompress(file_get_contents()) Or send it compressed if the browser supports this... if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) { $value = file_get_contents(); } else { $value = gzdecode(file_get_contents()); }

It's been awhile since I've worked with page compression, but here's what I remember. This checks to see if content is being gzipped by looking at currently loaded handlers and checking for zend compression (php isn't smart enough). If their is already a gzipped buffer it fires ob_start, if not php will start a gzipped buffer if the client supports compression, if not the output is not compressed (gz_handler is smart like that). if ((!ini_get('zlib.output_compression')) && (!in_array('ob_gzhandler', ob_list_handlers()))) { ob_start('ob_gzhandler'); } else { ob_start(); } As far as dealing with cached gzipped files, I wonder if you'll gain some performance by saving compressed data. There are php functions to dealing with compression, that will compress and decompress gzipped data. You'd handle this in the same way you would serialize data. gzinflate() - Inflate a deflated string gzdeflate() - Deflate a string gzcompress() - Compress a string gzuncompress() - Uncompress a compressed string gzencode() - Create a gzip compressed string A quick and dirty process flow would be something like this (keep in mind I haven't used the pro cache module nor do I understand yet how the default caching works)... save compressed data to file on the next page request start gzip if it's supported by the client else start the regular buffer route the request and get the cache file decompress and unserialize the cache file and dump into the current buffer. Data is uncompressed at this point and only compressed back if gzip is supported by client. (I wonder if it's possible to dump a compressed cache file into the current buffer and only decompress if the client doesn't support compression.) flush the buffer and display the page As far as advantages, there are probably less for PW. I see using gzip with php as an advantage in distributable applications targeting users w/ little to know programming or server admin knowledge. For those folks on shared hosting who want to install and go without hassle, this is a good option for them. It provides a big boost in performance w/o the additional configuration of apache or apache modules. Perhaps another advantage is being less dependent on the server environment and knowledge of the end user and controlling more aspects of how the app works inside of the app. All of that being said, in most cases Apache will be a better choice followed by zlib compression. Apache will also compress the js and css. The disadvantage is not all of your community will be running mod_gzip and may have no option to enable it (shared hosts). A config checkbox would allow advanced users to turn it on/off php compression if they wanted to use other methods like apache or zlib. Even if you don't use compression with the output buffer, there could be enough of a performance boost to consider using it to compress your template files before saving them. Here's how to retrieve data Unserialize(gzuncompress(file_get_contents())).

Thanks diogo. Yes, this would be an issue to consider as horst points out there could be collisions. Thank you both for the input.

Thanks guys! This is helpful information.

I hear your points, and I think they are valid. PW doesn't need to be bloated.

That's a good point. You'd have to account for that in your programming or tell the user to rename the page if that happens. Larger organizations sometimes use content guidelines to prevent these types of problems. I think if your pushing out that much content, enough that there's a risk of this problem happening frequently, I'm not sure I'd use mod rewrite. It may be slower than PW url segments. I'd test, but I'd expect PW to use less resources and be faster. On the other hand, making the redirect prior to loading PW, may have the advantage. Does PW require a unique page name? If so this would not be an issue, because portal would be the page parent and anything1 would be the page name. If anything1 already exists PW would not allow you to save a new page with the same name. PW may only require unique urls at each level in the tree. For example you can have a page named contact under the site root and a different page named contact under the about page. PW may see those as unique which would create the issue you mentioned. /index/contact /index/about/contact There may be other arguments against using mod-rewrite, but it's by far the simplest and quickest approach that less experienced coders can use. I'm glad you pointed out that issue, it hadn't crossed my mind and it's important to consider if you are going to use mod-rewrite. Thanks.

If it were me... I would require a unique username, but also allow a user to login w/ their email address. For example, check for the username, if it's not found, check against the emails addresses in PW. I would not allow multiple accounts with the same email, however if you did want to, the passwords could determine which account would be logged into and if the passwords are the same... well login to the first account found. I just posted some comments about this in the wish list forum. Seems old fashioned not to allow email login, case insensitive usernames, and spaces in the user name (all of which could be easily turned on or off in the module settings). Eventually I'll fork the core login module if Ryan isn't interested in these ideas, because I need the login to be more user friendly. It's one of the biggest sources of frustration for people. Hopefully someday we'll have a way to do a one click login, maybe using a thumbprint. As an aside, and not in response to Soma's comment, but rather in response to Ryan's comments... Ryan you are one of the most diplomatic and professional people I've encountered online. Your replies are generally quite polished and devoid of ego and I imagine clients love you, because you are an easy person to work with. To Soma's credit, I've seen a few threads on here where I was in full agreement with him and not with Ryan. Not because Ryan's answer isn't valid, but rather because my needs more closely matched Soma's. In these types of debates, there's never just one right answer, the right answer is always relative. What Ryan occasionally needs is someone to be the tie breaker. I've always found working with two other smart people (trusted advisors) to be very beneficial for this reason.

Is there some reason the user name can't be case insensitive and contain spaces? I want to login with a username like... "John Doe" or "john doe" interchangeably and I suppose space could be optional too, e.g. "johndoe". And while we are at it, why not also allow users to enter their email address and password instead of just username and password. This seems like a friendlier login system.

Keep me in mind if you are still looking. I'm also a very experienced Drupal dev.

You can also add this to your .htaccess file. RewriteEngine On RewriteBase / RewriteRule ^portal/(.*)$ $1 [R,NC,NS,L] Basically it's just removing portal /portal/anything/anything to /anything/anything e.g. /portal/catering/decorator -> /catering/decorator /portal/weddings/rentals -> /weddings/rentals

I'm being pedantical by pointing this out, it's not all that important, but... <?php echo "<a href='{$config->urls->root}'><h1>{$homepage->headline}</h1></a>"; ?> should be <?php echo "<h1><a href='{$config->urls->root}'>{$homepage->headline}</a></h1>"; ?> Inline elements like a can't contain block elements like h1. In other words the H1 tag can contain links, but links can't contain headings, divs, etc. *Really it doesn't matter, it should still display fine in most browsers, but I've found better compatibility with older browsers and future browsers by sticking to the w3c standards.

$1,200.

Andrey, I would love to build this in PW, but you will need a substantial budget. 16-32 design documentation 80-120 hours development time plus 30% overhead and to account for some scope creep and unexpected problems So were already close to 200 hours and that's just to build. That doesn't take into account any time for branding/logo/web design (the visual presentation of your site). If these are things you have considered and you can afford to build this, send me a PM. Thanks!

<?php if ((!ini_get('zlib.output_compression')) && (!in_array('ob_gzhandler', ob_list_handlers()))) { ob_start('ob_gzhandler'); } else { ob_start(); } ?> This is a minor improvement to take into account Valery's comment above. It checks to see if php zlib.output_compression is enabled. It doesn't check to see if Apache is using compression. This may be a solution to that: http://stackoverflow.com/questions/9397295/how-to-check-if-gzip-compression-is-enabled-with-php

Thanks, that's a good point. I also wondered if changing the default names would be confusing to some, so I appreciate you listing them. Here's another approach which would cover the scenario in which the pages are cached to a static file. To use mod_rewrite to handle gzip, you'd add something like this to config or htaccess: <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP:Accept-Encoding} gzip RewriteCond %{REQUEST_FILENAME}.gz -f RewriteRule (.*\.(js|css))$ $1.gz [L] </IfModule> AddEncoding x-gzip .gz <FilesMatch .*\.css.gz> ForceType text/css </FilesMatch> <FilesMatch .*\.js.gz> ForceType application/x-javascript </FilesMatch> http://www.cravediy.com/59-Simple-gzip-Support-for-Apache-with-mod_rewrite.html

Here's an example of the performance boost I gained by doing this... My page was 26kb before, and 4kb after. Page loading time was reduced by almost half. In site/config.php uncomment $config->prependTemplateFile and $config->appendTemplateFile = '_out.php'; /** * prependTemplateFile: PHP file in /site/templates/ that will be loaded before each page's template file * * Uncomment and edit to enable. * */ $config->prependTemplateFile = '_in.php'; //you can name this file whatever you want /** * appendTemplateFile: PHP file in /site/templates/ that will be loaded after each page's template file * * Uncomment and edit to enable. * */ $config->appendTemplateFile = '_out.php'; //you can name this file whatever you want Create two new files in site/templates called _in.php and _out.php. In _in.php add the following at the top of the file (before any code that you add later) <?php if (!in_array('ob_gzhandler', ob_list_handlers())) { ob_start('ob_gzhandler'); } else { ob_start(); } ?> In _out.php add the following at the bottom (after any code you add later) <?php ob_end_flush(); ?>

I would use the config options in site/config.php for including functions (ver. 2.2.3+ i think, maybe it's 2.3+)... /** * prependTemplateFile: PHP file in /site/templates/ that will be loaded before each page's template file * * Uncomment and edit to enable. * */ $config->prependTemplateFile = '_in.php'; /** * appendTemplateFile: PHP file in /site/templates/ that will be loaded after each page's template file * * Uncomment and edit to enable. * */ $config->appendTemplateFile = '_out.php'; In _in.php you can set up things that need to happen for each template. The nice thing about this option is not having to use an include statement on each of your template files. In my _in.php example below I'm initializing fredi and including functions. That's about all I'm using _in.php for. $fredi = $modules->get("Fredi"); include("./includes/functions.php"); Your approach is a nice one. You could also wrap ob_start around all output and gzip it. PW may already do the gzipping, I don't know. //compress the output for faster page loads ob_start("ob_gzhandler"); //output from your includes needs to be sent back with a return //e.g. return $html_string; or return $data as an array $body[] = include './teaser.php'; $body[] = include './pager.php'; $page->body = implode("\n",$body); //you can also use file_get_contents on a public url //(but you'll need to bootstrap PW if you need access to $page,$pages, etc.) //e.g. file_get_contents('http://www.mysite.com/my_php_include.php'); //depending on needs, maybe easier just to... //include './teaser.php'; //include './pager.php'; //$page->body = ob_get_contents(); //ob_clean include './main.php'; ob_get_clean(); Here's what the contents of teaser.php could look like... //this gives you some flexibility to format data as you wish and is helpful if you want agnostic data //you can also use this approach to create your own template system. (e.g. regex replacement {{body}} with $page->body) switch ($input->urlSegment1) { case "csv": //format data for cvs, save to file, provide download link break; case "xml": //format data for xml break; default: //format data for html foreach ($page->children as $a) { $data[] = "<li><a href=\"#{$a->$name}\">{$a->title}</a></li>"; } return "<ul>" . implode("\n",$data) . "</ul>"; } And while you are at it, maybe the better approach is to put ob_start("ob_gzhandler"); in _in.php and ob_get_clean(); in _out.php. Really just depends on what you want to do, but you can see how damn cool PW is.