Leaderboard

Maybe a useful addition: $sanitizer->entities() Cheers Btw the cheatsheet is the best API overview/explanation ever seen! Thanks for making this.

Feb 8, 2013 Announcement Page with download link MAMP & MAMP PRO 2.1.2 PHP versions updated MySQL version updated Apache version updated phpMyAdmin version updated Programs and libraries: Apache HTTP Server 2.2.23 PHP 5.1.6, PHP 5.2.17, PHP 5.3.5, PHP 5.3.6, PHP 5.3.14, PHP 5.1.20, PHP 5.4.4, PHP 5.4.10 MySQL 5.5.29 phpMyAdmin 3.5.5 SQLiteManager 1.2.4 Alternative PHP Cache (APC) 3.1.9 curl 7.24.0 eAccelerator 0.9.6.1 Expat XML Parser 2.0.1 FreeType 2.4.8 gettext 0.18.1.1 jpeg 8d libiconv 1.14 Libidn 1.17 libmcrypt 2.6.8 libpng 1.5.7 libxml2 2.7.8 libxslt 1.1.26 Sablotron XML processor 1.0.3 t1lib 5.1.2 XCache 1.2.2 XCache 1.3.2 Xdebug 2.2.0 PHP/YAZ 1.0.14 YAZ 4.0.1

The profile exporter will create an SQL file and package up all your files. You can then run an install with a fresh copy of PW with your archived files - full instructions are with the module and it walks you through it. Otherwise, you can easily just move the entire PW directory over to a server, export your own SQL, and then just change the database settings in config. One note, whichever you do, if you are adding images via TinyMCE, it saves the path to the image folder. If you are developing in a subdirectory, that will be part of the path. You can do a search/replace within the database to change this later, but what can be easier is to make sure the development set up is the same as the final production site. (Especially if two of you are working on the same thing!)

ProcessWire Skyscrapers Site Profile This is the profile for the skyscrapers demo site as seen at: http://processwire.com/skyscrapers/. This site profile release also coincides with some upgrades to the Skyscrapers site. The updates were to re-do many of the template files to make them easier to read, convert some classes to functions (easier for folks to understand), and convert the maps to use the FieldtypeMapMarker module. The main differences from the live site are that this profile excludes most of the photos and skyscraper text. Only the photos taken by me are included. This is to ensure we aren’t distributing any text or photos in case the license ever changes to something other than Wikimedia Commons. I can change the text/photos on my skyscrapers site, but can’t on any sites someone else sets up with this profile, so figure it’s better to play it safe. Requirements ProcessWire 2.3 OR ProcessWire 2.2 dev branch (2.2.12 or newer) ZIP How to install Get the latest version of ProcessWire 2.3. At the time this text was written, ProcessWire 2.3 wasn’t yet released, so if that is still the case you’ll want to get version 2.2.12 or newer from the dev branch. Before running the installer, replace all the files/directories in the /site-default/ directory of ProcessWire with those from this site profile. This includes the following: /site-default/config.php /site-default/install/ /site-default/modules/ /site-default/templates/ [*]Now run the installer to complete the installation. Template details The template files in the profile take the approach of populating variables that are output within a main/shared markup file. This is different from the basic profile that ProcessWire comes with. Specifically, make note of the following files: /site/templates/_init.php – This file is automatically included before any template file is executed. We use it to initialize the variables we populate and include a shared library of functions. /site/templates/_out.php – This file is automatically included after any template file is executed. In our case, we use it to contain our main markup that also outputs the variables we populated. /site/templates/includes/functions.php – This is where we are keeping a shared library of functions, most for generating skyscraper list markup. /site/templates/*.php – These are the site’s template files, each named consistently with the page(s) they represent. The primary focus of these files is to populate the $content variable that is output by _out.php. The use of _init.php and _out.php are something new to ProcessWire 2.3. These are specified in the /site/config.php: $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_out.php'; Use of this new feature is optional. We’ve used it in this profile because it reduces the amount of redundant include() code necessary in each of our template files. Download Skyscrapers Profile at GitHub or download ZIP file Skyscrapers Profile at modules.processwire.com Remember that you must have ProcessWire 2.3 (or 2.2.12 dev branch) or newer to install this profile.

Texformatter modules aren't autoload they only get called when needed. You'd have to make it autoload to use the init in the backend, but then it's not when it's called but when autoloaded in the admin. Then you could use init to add a hook InputfieldText::render there for fields that use that this textformatter.

With Aptana, I have always tended to create a project, set up the connection and then sync to download all the files. Then set it so when you save it syncs automatically. That way you keep a local copy which is always a nice thing to have. There is also a plugin for managing the database, though I only used that once ages ago. One trick that I never got quite right is with using Workspaces. A big problem with Aptana is the background indexing and if you have too many active projects in your workspace, then the system can get really laggy. Apparently, using workspaces for small collections of related projects helps since you are only accessing what you need. Making currently unneeded projects inactive is also worth while

Thanks wanze and apeisa, works like a charm.

This is the only reason I'm using my Macbook - There is Coda 2 (from Panic) and - in my eyes - it is the perfect solution for web developement like Processwire templates(little bit PHP, mixed with HTML and CSS). A non-commercial solution for Windows is Aptana but I thnk it is kinda overloaded with features and slow. Currently, I'm testing Webdrive FTP. I can mount my FTP Dir to the explorer and then every editor can use it as a normal directory.

Just to stir the pot.... This also works with the Thumbnail (crop-image) module/field type. So you might set two thumbnail sizes (under Input in the field settings): thumbnail,160,100 largethumb,800,600 And then, within your loop you would do something like: <a class="fancybox" rel="group" href="<?php echo $news_item->news_image->getThumb('largethumb'); ?>"> <img src="<?php echo $news_item->news_image->getThumb('thumbnail'); ?>" /> </a> Where news_image is the name of your thumbnail image field and fancybox is the class that fires fancybox if are using that (or for what ever lightbox type system you are using) This is slightly overkill for your use, but it is a useful way of doing it and allows you to have multiple sizes to play around with if you want to go completely mad. There are cases for using Repeaters for this sort of gallery, however. For instance if you want to have overlays on the images with full HTML rather than just the description box, or you want to add lots of other information to the image display. Joss

Hi netzartist – welcome to the world of Pw! Don't use repeater fields for multiple images. You achieve the same with the "Image" Fieldtype by setting maximum files = 0. This way you can upload and store multiple images with descriptions. You can do these steps: - Remove the repeater from your template - Change the "maxiumum files allowed" of your images field to 0 - Add the image field to your template - Upload multiple images Then your code needs minor changes: foreach($page->children as $news_item) { ... //images is the name of the Image Field if (count($news_item->images)>0) { foreach ($news_item->images as $image) { <?= $image->width(250)->url; ?> <img src="<?= $image->width(250)->url; ?>" width="250" alt="" title="<?= $image->description ?>" /> } } } Here's why your code didn't work: foreach ($news_item->image_repeater as $image) { //$image is not yet your image field, it is an "Item" of your repeater which can contain multiple fields } //This would work, but if you only need multiple images, don't use a repeater foreach ($news_item->image_repeater as $item) { $image = $item->image; //... }

Thanks for sharing. "Just copy the SmartyTemplating folder to your /wire/modules/" ... That's plain wrong. Never use /wire for modules and such. It's the core and if you provide 3rdparty modules they are always in /site/modules.

Thanks guys. I've just changed the release status to "stable", as there haven't been any real bugs to turn up, and I'm now using it on several production sites. If anyone is interested in seeing more details about the Apache bench test results I did, here they are. This is to the skyscrapers homepage, testing on localhost using the command "ab -n500 -c10 localhost:8888/skyscrapers/demo/". For all tests, I performed a manual pageview to the homepage before running, just to ensure the relevant cache was already active. The server is MAMP running Apache with PHP 5.4.4 on a Mac Pro (early 2008). ProcessWire is version 2.2.13. No caching enabled: Concurrency Level: 10 Time taken for tests: 29.066 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 11567500 bytes HTML transferred: 11361500 bytes Requests per second: 17.20 [#/sec] (mean) Time per request: 581.310 [ms] (mean) Time per request: 58.131 [ms] (mean, across all concurrent requests) Transfer rate: 388.65 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.7 0 8 Processing: 463 578 59.5 567 810 Waiting: 455 569 59.4 558 792 Total: 463 579 59.5 568 810 Percentage of the requests served within a certain time (ms) 50% 568 66% 591 75% 610 80% 622 90% 661 95% 693 98% 738 99% 760 100% 810 (longest request) Built-in Page cache enabled: Concurrency Level: 10 Time taken for tests: 6.809 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 11576500 bytes HTML transferred: 11370500 bytes Requests per second: 73.43 [#/sec] (mean) Time per request: 136.178 [ms] (mean) Time per request: 13.618 [ms] (mean, across all concurrent requests) Transfer rate: 1660.35 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.3 0 4 Processing: 93 135 17.6 132 249 Waiting: 90 130 15.7 127 236 Total: 93 135 17.7 132 249 Percentage of the requests served within a certain time (ms) 50% 132 66% 137 75% 141 80% 144 90% 154 95% 166 98% 187 99% 211 100% 249 (longest request) ProCache Enabled: Concurrency Level: 10 Time taken for tests: 0.117 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 11529500 bytes HTML transferred: 11370500 bytes Requests per second: 4260.61 [#/sec] (mean) Time per request: 2.347 [ms] (mean) Time per request: 0.235 [ms] (mean, across all concurrent requests) Transfer rate: 95942.85 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 1 Processing: 1 2 0.5 2 4 Waiting: 1 2 0.5 2 4 Total: 1 2 0.6 2 5 Percentage of the requests served within a certain time (ms) 50% 2 66% 2 75% 3 80% 3 90% 3 95% 3 98% 4 99% 4 100% 5 (longest request) ProCache Documentation and Order/Download page.

ProcessWire now implements ALL of the jQuery traversal functions in the Page API. Existing ProcessWire versions already implemented most of them, but once we started updating parent() and parents() to support selectors, I figured we might as well be fully complete and consistent with the jQuery equivalents. Now we are. The following functions were added or updated: $page->parents([$selector]) -- Now you can specify a $selector and it will return parents that match your selector. $page->parent([$selector]) -- Now you can specify a $selector and it will return the closest matching parent. $page->closest($selector) -- Same as parent($selector) except that it considers the current page in addition to the parents. $page->parentsUntil($selector, [$filter]) -- Return all parents from current till the one matched by $selector, optionally filtering them afterwards by $filter (a selector string). Note that $selector may be a selector string, a Page, a path, or an ID. $page->next([$selector]) -- Now you can specify a $selector and it will return the closest matching next sibling. $page->nextAll([$selector]) -- Returns all siblings that come after this $page, optionally filtered by a $selector. $page->nextUntil($selector, [$filter]) -- Return all sibling pages after this one until matching the one specified. Optionally filters the results by $filter, which is a selector string. Note that $selector (the first argument) may be a selector string, a Page, a path, or an ID. $page->prev([$selector]) -- Now you can specify a $selector and it will return the closest matching previous sibling. $page->prevAll([$selector]) -- Returns all siblings that come before this $page, optionally filtered by a $selector. $page->prevUntil($selector, [$filter]) -- Return all sibling pages before this one until matching the one specified. Optionally filters the results by $filter, which is a selector string. Note that $selector (the first argument) may be a selector string, a Page, a path, or an ID. Arguments in [brackets] are optional. These functions duplicate the arguments and behavior of their jQuery counterparts. The exceptions are that parent(), next(), and prev() have a slightly different behavior: they will traverse to find the closest match (which I thought was a lot more useful in our context). In jQuery, they don't traverse beyond the direct parent/next/previous item in the DOM. As before, all the next and prev functions should be used cautiously when $page has a large amount of siblings. All these functions require loading all the pages they interact with, as comparisons are done in memory and not via SQL queries. All of them accept an optional last $siblings argument, which is a PageArray of siblings you want it to analyze (which is presumably a more limited set), and this is what you'd use if you need to scale to thousands of pages when using these functions. But if you aren't dealing with huge amounts of pages, then you don't need to consider this.

$class = $child === $page->rootParent ? " class='on'" : ''; is a short way of writing if($child === $page->rootParent) { $class = " class='on'"; } else { $class = ''; } $page->rootParent gets the ancestor that is closer to the root (a direct children of the homepage). If you change the homepage variable to a something different from the root, they will never match. For this to work you have to replace $page->rootParent for this page's ancestor that is closer to /en/. Put something like this after the first lines: foreach($page->parents as $v) { if($children->has($v)) { $newRootParent = $v; } } Then replace $page->rootParent by $newRootParent. I'm not on my computer, and I can't test this right now, so, no guarantees here