Leaderboard

Hi all – Yep, Wikipedia is finicky about case. I've just now tweaked the Toolbelt template so that link goes through wikipedia/special:search, which will ignore case and link to the page if it exists – the link works fine now. Also, it's possible to just rename the page with the "rename" link in the edit dropdown – I'll fix that now too. Cheers – peter@toolbe.lt

I'm not sure what you mean by the pageArray method, but if what you mean is the Page FieldType, you should be able to do this: $color = $pages->get("color_code=0x00f"); $page = $wire->pages->get("parent=/boxes/, color=$color"); edit: oh, didn't see the previous posts... they appeared while I was writing

You might try creating a new field using the FieldtypeCache type. This isn't installed by default, but it is included with PW, so you'll just need to click "install" from the modules menu. This field essentially keeps the values from several fields in one field, so that they can all be loaded at once as a group. Like all caches, it's creating duplication and trading disk space for speed. These cache fields are also handy if you are building a text searching engine that needs to scan lots of fields at once... your selector can query just the cache field rather than "field1|field2|field3|etc". Once installed, create the new "cache" field, click to its "details" tab and follow the instructions there. Don't make it autojoin. Instead, have your output generation code reference the cache field field (like $page->my_cache) before any of the others that are triggering queries. This should enable you to reduce it to just one query for all those fields. I'll be honest and say I created this fieldtype with many good intentions, but have rarely found it necessary to use. So be certain the situation you describe really is the bottleneck, and that you aren't omitting pagination or accidentally referencing something like $page->children() or $page/s->find() without a "limit=". The reason that I mention it is that MySQL selects are extremely fast, to the point where the difference between autojoin and non-autojoin may require some scale before you can measure the difference. If you are query counting, avoid doing that, as it often doesn't correlate with performance, especially in ProcessWire. (I used to be a big query counter until I read the book High Performance MySQL, which is reflected in PW's DB query approach). One other idea you might look at is temporarily convincing the fields in question at runtime that they are autojoin, before loading your pages: foreach($selectedFields as $fieldName) { $field = wire('fields')->get($fieldName); $field->flags = $field->flags | Field::flagAutojoin; } That's assuming all the fields in question support autojoin. Some fields, like files/images, can't be autojoined and telling it to may cause unpredictable results.

Ok, I got a little time and did it myself Please go there and change it as you wish. http://toolbe.lt/Processwire

ProcessWire2.+ Minify 1.0.3 This module helps you combine Javascript and CSS files into one, minified file to save on unnecessary HTTP requests and to compress files anywhere up to 80% (including already minified .js files). To use it, extract the attached zip file into your /site/modules/ directory and check for new modules in the ProcessWire Admin area, then install the module. Once installed, go to configure the module and, instead of this configuring anything for you, you can use the drop-down lists to build stylesheet and script code to place in your templates, grabbing a list of any stylesheets and scripts it finds in the /site/template/styles/ and /site/templates/scripts/ directories respectively. It's more of a helper than anything else, but it should take the guesswork out of configuring Minify for your site. Notes: This module contains a third-party library - Minify - which is subject to its own license (a copy is included in the attached zip file). I've left the module in-tact including its unit test files so there are more files than are necessary, but this will make it easier for me to upgrade the module if/when they release updates to that code. This module doesn't insert any code into your templates automatically - I think copying and pasting the code it currently outputs to the screen is more useful/configurable for more situations. It's worth using even if you only have one CSS or JS file as it will compress CSS files by about 80% and JS files by quite a lot too, plus since it handles caching on the server-side and does its own checks of the files it is serving (plus it's a dynamic URL), you can always be sure that it will serve the latest version of a CSS file (no more CTRL+F5 to show the new styles if your browser decides to cache it. You can change the /site/modules/Minify/min/config.php as you could if you were using Minify as a standalone script - tweak cache paths (default is your server's cache path) and other advanced settings here. Updates: v0.0.2 - now produces code that includes paths derived by ProcessWire at run-time so paths will be fine on localhost and live servers, removing potential issues when pushing a site live. v1.0.0 - bumped this up to a major version number since there appear to be no issues with the initial versions to speak of. Also implemented yellowled's input field suggestion (looks much better and easier to select for copy and paste purposes) and turned off autoload at ryan's suggestion. v1.0.1 - now recusrively searches for files inside subfolders under the scripts and styles directories using PHP 5's built-in iterator classes v1.0.2 - pull request from teppo - https://github.com/Notanotherdotcom/Minify/pull/1 v1.0.3 - updated Minify code to v2.1.7 which fixes a significant security flaw: https://groups.google.com/forum/#!msg/minify/cpN-ncKPFZE/kwYVpLMkfDwJ You can download the module here.

Hey Buddy I would be insterested what the "usual" way is? Decodesiffering your post... I think you can simply first query the color pages. It will give you a PageArray with the color pages, with that you can then use directly to find the pages with these colors selected through a page field. // get all pages with at least 1 of these colors, this will return a page array, if you echo it you'll get a list of IDs // here "color" is the text field with the color string $pagesForColor = $pages->find('color=0x00f|0x0f0|0xf00'); // we find all pages that have at least one of the colors selected // here "color_select" would be the page field $result = $pages->find("parent=/boxes/, color_select=$pagesForColor"); It's that what you're looking for? PS: Don't use $page or $pages variables for the results of queries. YOu may overwrite the template system variable with that name.

One other comes to mind. If you have multiple albums on same page, you could create a js config object with the different albums images. var albums = { album1 : [ {href: 'image1', title: 'Title1'}, {href: 'image2', title: 'Title2'}, ], album2 : [ {href: 'image1', title: 'Title1'}, {href: 'image2', title: 'Title2'}, ] }; Then create the album fancybox links: <a href="#" rel="album1" class='album-link'>Album1</a> <a href="#" rel="album2" class='album-link'>Album2</a> And the fancybox init script like this: $('.album-link').bind('click', function(e){ e.preventDefault(); var name = $(this).attr('rel'); $.fancybox( albums.name, { .. options .. }); });

Everything in admin is specifically excluded from the search results (including users) and has been for a couple months I think. Mainly, I just got sick of all my repeater values taking over my search results. I was mistakenly not thinking about users... I'll change this so that if you specify a template it won't exclude anything from superuser.

Hi Ryan, I think there might be an issue with the search (in PW admin) in 2.2.5. It seems to fail when searching for anything within the /admin/ pages.

I've just made that function public, so should appear in the source shortly. But I'm thinking Soma's jQuery solution seems like a pretty great one.

I love this kind of questions. I think one simple solution would be to have the list of images loaded via ajax (bootstrap PW and return the image array) or render a js object on the album page you will simple use when opening fancybox. Simplest solution for now (other solutions up to others slower posters): Add a link somehwere to the album <a href="#" class="showgallery">Show Gallery</a> The jquery will be like this. $('a.showgallery').fancybox([ {href : 'img1.jpg', title : 'Title'}, {href : 'img2.jpg', title : 'Title'} ], { ..fboptions.. } ); Print that script using php and add the images string on runtime. <?php $imgstr = ''; foreach($images as img) $imgstr .= "{href : '".$img->url."', title : '".$img->description."'},"; ?> $('a.showgallery').fancybox([<?php echo substr($imgstr, 0, -1); ?>], { ..fbconfig.. }); Done. Not tested but you get the idea.

Okay, I updated this to 1.0.1 to search recursively for files under the /site/templates/js and /styles folders - this is available from the modules directory as v1.0.1. I thought I'd work on v1.0.2 which lets you specify starting folders further up the tree whilst I'm at it but have hit a snag. It works fine, but when you change the path and hit save the drop-downs don't update their path unless you save the module a second time. Anyone have any ideas why you'd need to save the module twice for the config page to be able to use an updated value?

It's not possible in a convenient way, because the page field is special and not working the same as a text field. It has it's own method of adding the inputfield. So a check would be needed to look for if the inputfield is of type InputfieldPage and then do different code to set attribute for it's inputfield. But since the methods in the InputfieldPage are protected it isn't possible to do the following example: foreach ($inputfields as $inputfield) { if($inputfield instanceof InputfieldPage){ $inputfield->getInputfield()->setAttribute('class','span3'); // will fail cause method is protected } else { $inputfield->setAttribute('class', 'span4'); } $form->add($inputfield); } InputfieldPage.module #101 protected function getInputfield() { If Ryan could make it change to something it could be accessed the above code would work. I don't see any other way right now. So, for now you could do a regex replace script to parse the returned html string from ->render() before outputting. Not simple if you don't know. But, here's the most simple way using jQuery. $('select[id^=Inputfield]').addClass('span4'); Voila.

I'm not angry just lazy

Found one bug from latest version. If you only allow certain template as a child (like a blog-post under blog), then publishing those pages fails to this error msg: Missing required value (template) Reason for this is simple, this is how the template dropdown is on code: <select id="template" class="required" name="template" disabled="disabled"> <option selected="selected" value="48">blog-item</option> </select> Since it is disabled, then it wont be posted at all. I think there is two possible fixes: either make template selection not required or then just remove the disabled="disabled" attribute and use plain text and hidden field instead. Not sure if readonly (which is similar to disabled, but still sends the data) works with selects.

$page->images would only work of your images field was called "images" otherwise as you say it would be "the_image_field" if that's what you called your image field. $page->image_field_name->url gets you the URL and ->description on the end instead of url gets you the image description if you entered one.

It's possible that there is some site out there using ProcessWire with hundreds of thousands of pages, but if there is, I don't know about it yet. I haven't gone above ~50k pages myself, though I don't think it would be a problem to scale as large as you need it to. It's not like an odometer on a car where there is a max upper limit and the higher you get, the more you are taxing the system. Whether your site has 100 pages or 100k pages, ProcessWire itself isn't dealing with any more data at a given time (only MySQL is). Scale should not affect the performance of the admin UI either. I actually think that the admin lends itself very well to large scale, and the larger scale you go, the more you'll appreciate some of the ways it does things. That's what it was originally designed for after all. As scale increases, you just have to be more careful about how you develop things. You need to be conscious of calls like $page->children and be sure you are placing limits on quantity of results returned from such functions, i.e. $page->children('limit=50'); More about that here. When dealing with high traffic, you need to consider caching at various levels. Know when to use template caching and markup caching. Optimize some situations with autojoin fields. You might also investigate FieldtypeCache to potentially reduce page load times and increase the speed of multi-field text searches. Make sure your PHP is running with an opcode cache like eAccelerator or APC. I'm also working on an htaccess/rewrite cache for ProcessWire (like WordPress W3C Supercache), but it's not done yet. The advantage of this will be that you can direct some pages to be delivered directly from the markup file (via some complex rewrite rules), bypassing PHP, MySQL and ProcessWire completely. I don't have anything to add about multi-server setups, but interested in hearing if anyone else has experimented here.