ryan

$_SERVER['DOCUMENT_ROOT'] would have to be the same as $config->paths->root in order for that to work. Usually they would be, but sometimes they aren't, whether due to a subdirectory install or aliases/symbolic links. You'd probably want to set it like this instead, which should work (unless I'm forgetting something): $home->template->filename = wire('config')->paths->root . 'basic-page.php'; Also, since your basic-page.php is not protected by PW's .htaccess, put this at the top: if(!defined("PROCESSWIRE")) die('No access');

You can configure the behavior of when the cache is cleared. But when you save a page, the cache is always cleared for that page, regardless of any other behaviors you've set. The other built-in options are to clear all children (and everything below), clear all parents (except homepage), clear homepage, or clear site. Another thing is that even a short 5-10 minute cache is hugely beneficial. That means that your page will only be rendered a max of once per 5-10 minutes, even if it gets hit thousands of times in that period. And the shorter the cache time, the less chance someone will ever see stale data. While I think we all have a tendency to make the cache time as high as possible (like an hour, a day, or a week), the right balance is often a much shorter time period. This would especially be the case if your site involved lots of page-to-page relations that fall outside of the tree relationship. Can you explain this a little more in detail. I'm on a shared Plesk Hosting Enviroment. This is not related to the hosting environment. Instead, it means that if you have code in your template files that is performing actions based on the hostname, then ProCache doesn't yet recognize that. For instance, if you are doing anything that checks $config->httpHost in your template file, you wouldn't want to cache that page with ProCache (or the built-in page cache, for that matter). This is an example of a template file you wouldn't want to cache: if($config->httpHost == 'de.domain.com') { $user->language = $languages->get('de'); } else { // www.domain.com // keep default language } However, I will be upgrading ProCache so that it saves the hostname with its cache files so that such a template file could still be cached.

What is your /path/to/file.php? Here's the actual code from Template::setFilename that gets executed when you do $somepage->template->filename = '/path/to/file.php'; protected function setFilename($value) { if(empty($value)) return; if(strpos($value, '/') === false) { $value = $this->config->paths->templates . $value; } else if(strpos($value, $this->config->paths->root) !== 0) { $value = $this->config->paths->templates . basename($value); } if(is_file($value)) { $this->filename = $value; $this->filenameExists = true; } } Look at the "else" condition above, which is what's enforcing your template file to be somewhere below PW's root installation dir.

Very interesting and unique--I like it! I look forward to trying this one out.

Just to confirm, you were able to solve it by uncommenting the "RewriteBase /" line in .htaccess?

When using pagination, make sure you set "start=0" on any other non-paginated, DB-selector based calls that include a "limit=n" in them. Otherwise it'll attempt to paginate those too.

This is actually the purpose of $user->language->isDefault(), so that you can differentiate the default site language from all others in one shot, without having a dependency on any specific language. This is largely contextual to a website. If a new user arrives at your website and has not selected a language, what do they get? That's what the default language is about.

Another way to check for homepage is just if the $page->id === 1; because the homepage always has an ID of 1.

You can also do this: $u = $users->add('gonzo'); if($u->id) { $u->firstname = 'Gonzo'; $u->lastname = 'Ipsum'; $u->pass = 'BamBam!'; $u->addRole('guest'); $u->save(); } else { echo "That username is already taken, please choose another"; } The benefit of using $users->add() is that it actually creates and saves the user before you populate it, meaning you can exit out earlier if there is some error. But the main reason is that some fields (like files or images) require the page you are manipulating to have an ID before you can add files. So this saves you from having to think about that. If that's not a consideration, then it doesn't really matter which approach you take.

I personally wouldn't want my view link opening in new tabs/windows, but I can see why some would. I will plan to make it a configuration option on the ProcessPageEdit module. As for how to explain the current behavior to a client, I'm not sure it needs explanation because it works the same as any other form on the web. If you are completing a form and you navigate elsewhere, your form is not still there waiting for you. So if you want to say anything, that's probably the best way to say it: it works the same as any other form you've ever used on the web... as in "don't click to a link until you've finished your form".

The posted code example looks okay to me. But I'm not sure I understand the question… What is the "drop down module"? We'd probably also want to see where $country is coming from and where you are setting $input->whitelist->country. But most importantly, what is the expected output, and what output are you currently getting? Curly brackets only necessary if you've got two "->" in there, meaning, you can do this: echo "$page->title"; but not this echo "$page->image->width"; you'd have to do this: echo "{$page->image->width}";

You should be able to do this during runtime: $page->template->filename = '/path/to/file.php'; or $t = $templates->get('some-template'); $t->filename = '/path/to/file.php'; Note that /path/to/file.php must be a full path and filename relative to the server's file system, but PW won't accept it unless the file ultimately lives somewhere under your web root where PW is installed. Meaning, you can't do this: $t->filename = '/etc/passwd';

Hopefully you are getting at least some form entries though? There are a couple things in FormBuilder that will likely keep out most spam even if you don't enable any spam prevention measures. You are right that the iframe makes it invisible to most spiders, so that's one of them. The other is that it requires a unique submit "key" for each form submission, and it must match up with the key in the form that was presented, as well as the one saved in the user's session. Most automated spam isn't sophisticated enough to maintain sessions and retain values in hidden fields. They usually just populate every field available with their spam. So it's unusual for spam to get through a FormBuilder form, even if you aren't using any spam prevention measures.

Great site josedigital! I would have never guessed this used the blog profile as a base. Nice work! I think this is pretty common. This is really only an issue if you are selling digital products with instant delivery. In a case like this site, where somebody has to create or ship something, I don't think it's a problem. There's absolutely no benefit to manipulating the values. The paid amounts are almost always in the face of anyone fulfilling orders. If someone is manipulating these things to place an order, it falls under the category of "world's stupidest crimes." They are committing fraud while creating a permanent paper trail and providing personal info like a credit card and/or mailing address.

Thanks Nik -- I will get more familiar with PHPUnit and then work on the SubfieldTest. This is exactly right.

I haven't had a chance to fix this one yet, but if you need a temporary fix edit your /site/config.php and locate the $config->pagefileSecure line and change it to false: $config->pagefileSecure = false; Look in your /site/assets/files/ dir. If you have any directories with a preceding "-", then rename them not to have the "-" in it.

A resized image can't be sent back to the field to replace the image it was resized from. That's because it has a filename reflecting it's resize properties, and so it's considered a variation rather than a source image. Most likely your resized image was created and on the file system, but PW saw the source image and stuck with it. There isn't really any reason to replace a source image with a size variation here, because your size variation will be cached. It won't literally create it every time. But your code as it exists now will execute a page save every time. So you would be much better off just doing this in your template code: $photo = $entry->photo; $options = array('upscaling'=>true,'cropping'=>false,'quality'=>80); if($photo->width > $photo->height) { $photo = $photo->size(410,0,$options); } else { $photo = $photo->size(0,410,$options); } // the above only created a new image the first time it was run // so it's perfectly efficient to leave it there. // $photo is ready to use echo "<img src='$photo->url' alt='$photo->description' />"; Also, if you want to set max dimensions for an uploaded image, then you can set this from the image field's settings.

WillyC is right, you need to increase your nesting level in xdebug, or disable xdebug. ini_set('xdebug.max_nesting_level', $limit)

Joss, here's another way to do it too: foreach($pages->get('/news/')->children("limit=5") as $cnt => $item) { if($cnt == 0) { // $item this is the first child } }

@adamspruijt: ProCache caches URLs, and doesn't care so much what page they ultimately map to. So it works with regular pages, URL segments, page numbers, etc. It will also bypass the cache if any GET vars are present, unless you configure it otherwise. So long as the same URL like domain.com/path/to/page/ is always served in the same language, then you are good. But if you are serving different languages at the same URL, then a cookie or GET var would be the only way to bypass the cache.

Awesome work Marc!

So long as you are aren't serving different languages from the same exact URL, it should be totally compatible. If you are serving different languages at the same URL, then you've got to be concerned about search engines and such. But if that's not an issue, then you are right that you could accomplish it by setting a cookie and telling ProCache which cookie should bypass the cache.

ProcessWire is fast. With ProCache, ProcessWire is insanely fast! ProCache provides the ultimate performance for your website by completely bypassing PHP and MySQL and enabling your web server to deliver pages of your ProcessWire site as if they were static HTML files. The performance benefits are major and visible. Using ApacheBench with the homepage of the Skyscrapers site profile, we completed 500 requests (10 concurrent) to the homepage. The amount of time occupied to complete each of these was as follows: 29 seconds: no cache enabled 6 seconds: built-in cache enabled 0.017 seconds: ProCache enabled As you can see, the performance benefits are substantial. ProCache gives you the ability to drastically reduce server resources and exponentially increase the amount of traffic your server can handle. This is especially useful for traffic spikes. Beyond measurements, ProCache makes your website feel faster to users, respond faster to search spiders (which can help with SEO), and helps to conserve server resources for requests that actually need PHP and MySQL. ProcessWire is already very fast, and not everybody necessarily needs what ProCache delivers. But regardless of whether you need it or not, there is little doubt that you can benefit greatly from ProCache. For an example of ProCache in action, visit processwire.com or the skyscrapers site. Look in the lower right corner of the page (in the footer). If it says "ProCache", it means the page was delivered via ProCache. We did this for demonstration purposes (ProCache does not put anything in your markup unless you tell it to). More information about ProCache can be found on the ProCache documentation page. Please note There is a known issue when using ProCache with the LanguageLocalizedURL module. I hope to have this figured out soon, but for the moment you should not use ProCache in combination with that module as it doesn't appear to work in full. ProCache does not yet support multi-host capability (i.e. cache and delivery of different content per hostname), but it will very soon. How to get it Like with Form Builder, ProCache was produced as a commercial module to support development of ProcessWire. It is now available for purchase here. ProCache is in a beta test period. As a result, it's being offered with introductory pricing that may increase once we're out of that period. During the beta test period, I just ask that you let me know if you run into any bugs or issues during your use of ProCache. I also recommend that you follow the usual best practices with regard to backing up your site and testing everything before assuming it's all working. Beyond the introductory pricing, you may also use coupon code PWPC-BETA for 10% off the listed prices at checkout. This code will expire as soon as we're out of beta. When you get ProCache, you'll also get 1-year of access to the ProCache-members support and upgrades board, available here in the ProcessWire forums. Upgrades to ProCache will also be posted there for download. Disclaimer: At the date/time that I'm writing this, I think that I am currently the only one using ProCache in production use. That's why I'm providing it with the lower costs and coupon. If you are running production sites where everything must always work perfectly, you will either want to: 1) wait to install on important sites till it's out of beta; or 2) test thoroughly on a staging server or localhost before taking it to production use. In either case, always make sure you have good backups anywhere you install new modules, and always test to double check everything works how you want it to. Get ProCache Now ProCache Documentation Below are a few screenshots that show the configuration screens of ProCache. Have questions about ProCache? Please reply to this topic. Thanks for your interest in ProcessWire ProCache!

Okay, glad that works. There must be a container element between #CommentForm and form, and code in the first example assumes #CommentForm is the parent of form.