ryan

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.

Thanks, I sometimes forget we support uppercase chars in field names (I don't use them myself). We can't support uppercase in permission names, since they are ultimately page names. But I think I can make this case insensitive. This won't be a problem, as you can't have two fields with the same name from the DB side, of different case. Can you tell me if this update fixes it for you? https://github.com/ryancramerdesign/PageEditFieldPermission/commit/449dee6eabd3e7adc733ae829568f1828a5d87b5

Joss, I love the wording on your flyer. But is "advertsing" a British spelling (or humor... err humour?), or is that a misspelled word?

Not currently. Though I suppose you could create a module to hook the relevant components to do this. But the custom header name has come up as a repeated request, so this will be added pretty soon. The ability to have the items collapsed has also come up before, though not necessarily to have some collapsed and some not, but I'll look into it.

This is not planned for 2.3. Inclusion in 2.4 or 2.5 is more likely.

The tooltip() function is a recent addition to jQuery UI. The dev branch is using the new jQuery UI, while 2.2.9 isn't.

Could cause problems with modules that are loading other modules or populating JS/CSS files to $config->styles or $config->scripts. If your module is already an 'autoload' module, then it should be no problem since it's already loaded and obviously not a problem. But this is more of a consideration with Process, Inputfield and Jquery modules, that are loaded on-demand, as they do trigger loading of other assets. And you don't want those assets loaded unless the context is right for them to be loaded. Ultimately it just depends on what your module is doing. Since PW doesn't know what all the modules are doing, we needed a universally safe way to configure all modules, and a static method gives us that. But that doesn't mean that you have to stay static when you don't need to.

Not sure why the follow-up message wouldn't be shown. Was the comment still saved?

Thanks for testing. I don't have IIS to test with, so will just wait to see if this particular issue pops up for anyone else, before we try to debug it.

Joss, please add to the modules directory when you get the chance.

Sounds good, I'll get both files updated.

I was able to duplicate it here with the blank profile, but not other profiles. I tracked it down to the lack of a /site/install/files/ directory. It looks like the installer needs there to be a files directory present for some reason (something I think I can fix). And of course, this being a blank profile, it has no files. But to get this profile working today, all you need to do is make sure you have a 'files' dir in /site/install/. There doesn't have to be anything in it.

Nice work Joss! Tried it on my phone first, then on my desktop--works and looks great on both.

Doolak, I will go ahead and make this translatable and included in the core this week -- didn't realize I'd missed this one.

Thanks Radek, this has been updated.

I could be wrong, but I don't think that the Redirects module works with source URLs that have query strings or anchors. I think you'd probably have to handle these redirects from your .htaccess file. The /#/pagename/ style URL is an unusual URL mapping system. It looks like it's trying to hack around using homepage anchor links to deliver different pages. Usually anchors would be to jump to different parts of the same page (in this case, the homepage). Google probably saw that it's being delivered completely different content for different anchors, rather than the expected homepage with an anchor point. It's probably not great from an SEO standpoint. I'm not sure how to account for an anchor in .htaccess rules, but I'm certain you could account for the query string "?" version with apache rewrite rules.

Beautiful. Chrome is quite the artist.