Leaderboard

Pretty happy to see how you guys have sorted this out for the OP I'd just like to point out that foreach ($editpage->ad_publish_at as $t) { //ad_publish_at is my timestamps field $editpage->ad_publish_at->remove($t); } ...will be a lot slower than WireArray's removeAll(). The reason for this is that the implementation above causes a scan in the array (you are asking an object to be removed from the array). So while there is a foreach loop inside removeAll(), it's different, because it removes based on the keys of the array (which is faster). Changing the original implementation to foreach ($editpage->ad_publish_at as $k=>$t) { //ad_publish_at is my timestamps field $editpage->ad_publish_at->remove($k); } ...would have the exact same speed as removeAll(). But obviously if you don't need to do anything else to the object, it makes more sense to just use removeAll(). Edit: While I was writing you obviously confirmed this with your benchmark

Hello everybody, thank you for this vital discussion. We've updated Auto Name to Version 1.1, addressing some of the issues and thoughts of this thread. Changes: It is now possible to set a human-readable date format for the created and updated fields Renaming can now be restricted to unpublished pages Includes a fix for a bug that accidentally renamed system pages If you have any additional thoughts, please post them here or open up a ticket on GitHub! Thanks! Marvin

Just a pointer for those interested in why the first() method that diogo mentioned solved this; if you look at your page field "food_types" and switch to the details tab, you probably have the first option selected, like this... ...which is setup to return an array of pages, even if that array only has a single page in it. Now that's why you need to call first() as you need to select a page from the array that $page->food_types was returning. /** * Examples for a page field setup to return an array of pages... */ echo $page->food_types; // This won't work for an array return as you haven't drilled down to a page entry yet. $p = $page->food_types->first(); // Ah, now $p holds a page. echo $p->title; // And now we can show the title. echo $page->food_types->first()->title; // This works too, no need to assign to a variable if we don't want to. You stated in your opening post that food_types only has one page selected... Now look at the other two options for your page field in the screen shot. Both of those options return a single value when the page field is referenced. If you had picked either of those two options then your code would have worked as you'd have been given a page (or 'false' or a NullPage) directly without having to fish it out of an array. Anyway, hope that helps explain things a little more.

Sure, you can do whatever you want with PW! Put something like this in your template file, or change it to extend the WireArray class if you'd like // Adding the method "suhosinRandomTimed to the WireArray class $wire->addHook('WireArray::suhosinRandomTimed',null,'suhosinRandomTimed'); // Define the method, I added $num and $seed to make this easy to demonstrate function suhosinRandomTimed($event, $num = 2, $seed = 'Ymd') { $pages = $event->object; // This is the WireArray object, more than likely will be pages if(is_string($seed)) $seed = crc32(date($seed)); srand($seed); $keys = $pages->getKeys(); // changed all instances of $this to $pages since I'm not defining within class $items = $pages->makeNew(); while(count($keys) > 0 && count($items) < $num) { $index = rand(0, count($keys)-1); $key = $keys[$index]; $items->add($pages->get($key)); array_splice($keys, $index, 1); } $event->return = $items; // return the pages } $p = $pages->find("template=someTemplate")->suhosinRandomTimed(); // Call the method on the results of $pages->find echo $p->render(); Just change the function's body to do whatever you need it to be and you should be good.

Hello everybody, I'd like to introduce a new module to you. It automatically adjusts pages' URLs based on naming patterns. It allows you to specify a general pattern for all pages or individual patterns per template. It is available in the ProcessWire module directory. Also you may find the code here. New: Auto Name has been updated to Version 1.1. Changes: It is now possible to set a human-readable date format for the created and updated fields Renaming can now be restricted to unpublished pages Includes a fix for a bug that accidentally renamed system pages I'm looking forward to your feedback. Thanks in advance, Marvin

Sorry for poor communications from my part. New shop module is currently in closed beta testing. I am pretty busy at the moment (both work and personal), so there is not too much focus on this. For the pricing I am thinking something like 50€ - 99€ for single site license. Also currently (slowly) building full featured shop profile, that would be single purchase and free to use parts or fully as many times as wanted (single site license required for all new shops though).

@adrian Just tried your code and compared time for both methods. Deletion of 3073 timestamps. using $editpage->ad_publish_at->removeAll(); 0.2848 seconds using foreach ($editpage->ad_publish_at as $t) { //ad_publish_at is my timestamps field $editpage->ad_publish_at->remove($t); } 0.7537 So removeAll() is significantly faster and speeds up my application. Thank you! Cheers Gerhard

Was going to mention this earlier but it slipped my mind, so: Nico, what's your take on the storage method this module uses (saving all content to module config, i.e. the data column of related Modules table entry) and the obvious limitations it causes? Based on some quick testing, using suggested description length, this module should be able to store data for roughly 300 pages -- though actual number depends a lot on the stored data itself. I was just wondering if it would make sense to reconsider the storage method, offer an alternative method for large sites, mention this somewhere.. and/or perhaps make the module aware of how much "quota" it still has? I'm asking 'cause this seemed like an interesting choice for some of our sites, but it's not that rare for those to have hundreds or even thousands of pages.. so if the client ever gets too enthusiastic, there's going to be a problem Also: you might want to add garbage collection for removed pages. That's going to limit the scope of aforementioned scalability issue a bit.

http://www.foodloversdiary.com/good-stuff/the-bowl-of-good-food-we-can-all-invest-in/ and... https://twitter.com/foodloversdiary/status/524323670630469634 In case anyone wants to retweet...

try $hassidebar = array('home','project','projects','posts','partners'); if (in_array($page->template->name, $hassidebar) { //... } EDIT: adrian was quicker. Either of it should work.

@diogo Perhaps onjegolders is onto something (offering an illustration or illustrations) for potential donors who are not in Porto and can't benefit from your rewards with local delivery.

@kongondo My implementation is as follows. 1. installed the inputfield Timestamps module that you supplied. 2. created a field "ad_publish_at" of type timestamp and add it to my advertisement template 3. render the form on the frontend with code based on Soma's gist. 4. use a custom function to find recurrences from start and end dates in my advertisement template. The function uses the barely documented PHP DatePeriod class function getRecurrences($startTime,$endTime,$interval) { $format = 'Y-m-d H:i'; $start = new DateTime(); $end = new DateTime(); $start->setTimestamp($startTime); $end->setTimestamp($endTime); $end = $end->modify( '+1 minute' ); $duration = 'PT' . $interval . 'M'; //where $interval is 15, 30 or 60 $interval = new DateInterval($duration); $daterange = new DatePeriod($start, $interval ,$end); return $daterange; } 5. $daterange contains an array of DateTime objects. I loop through them, convert each into a timestamp and save that to my timestamps field $times = getRecurrences($startTime,$endTime,$interval); //this is the daterange array with DateTime objects foreach ($times as $t) { $t = $t->getTimestamp(); $timestamp = new Timestamp();//this is the Class Timestamp found in Timestamp.php. Included via FieldtypeTimestamps. $timestamp->date = $t; // note stored in column 'data' in the db of the Field $editpage->ad_publish_at->add($timestamp); } 6. when a user edits an advertisement and changes dates, I have to manually delete all previously saved timestamps, before I add the new ones with step 5 above. For deleting the "old" timestamps I use this foreach ($editpage->ad_publish_at as $t) { //ad_publish_at is my timestamps field $editpage->ad_publish_at->remove($t); } If you have any further questions on my implementation, please ask.

One of the key design concepts of ProcessWire is that you can use the same fields in multiple templates. Behind the scenes, the values of a field are always stored in the same table (regardless of the template where it is used). This makes it possible to query based on a field without even having to know in which templates it is used. In this respect, it would be completely ok to have multiple templates. Anyway, to answer your question. You cannot currently create a rule that's based on the parent using the default "Show if" -functionality. Now if you want to use the same template, have you considered making the category a Page-field? You could arrange your tree like this News * News item 1 (Category = Jobs) * News item 2 (Category = Jobs) * News item 3 (Category = Funding) Categories * Jobs * Funding The Category-field of the News-template would be a Page-field, that has it's selectable parents set to "Categories". On the frontend you could easily provide filters by listing the pages under "Categories". Implementing the categories this way you can use the built-in "Show if" -feature.

Upcoming update: Blog version 2.1.0. (dev) Summary of Changes: Added 'Small' Posts Featured Image setting EDIT: Note that the implementation of this feature has slightly changed. See this update: --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- As requested, Blog version 2.1.0 now includes a 'featured image' setting that can optionally be used when displaying a summary of posts (i.e. small/summarised/truncated posts). I haved added this to the dev branch for testing and comments, thanks. It is implemented by including a third argument/parameter to renderPosts(),i.e. renderPosts($posts, $small = false, Array $featuredImage = null) Only if $small = true and $featuredImage is also specified, does the setting kick in. $featuredImage must be an array of options to apply to the featured image as described below: First, renderPosts() will look for the first image with the default or specified tag (see below) in the post's blog_images field If no image found, it will then look for the first image embedded in blog_body (i.e. the body of the post). Here it uses PHP's DOMDocument class. if we find an image, we output it in ,<div class=post-body> just before the truncated post text (see screens below). The image is given the class <img class='post-small-featured-image'> If no image found, nothing is output and we move to the next post...etc... The above means that you can mix and match where your featured image will come from... The default image options are: //default featured image options $defaultOptions = array( 'width' => '',//no width manipulation if this blank 'height' => '',//no height manipulation if this blank. Note, if size is true and both width and height > 0, use size() instead 'alt' => 'description',//defaults to $image->description. Otherwise other stated field on the page, e.g. = 'title' 'tag' => $this->_('featured'),//string: image tag to look for in blog_images //size: image will be resized to exact dimensions -> $img = $image->size($x, $y) //where $x = 'width' and $y = 'height' 'size' => false,//if 'size' = true AND both width and height > 0, this kicks in ); Above are self-explanatory but let me clarify a few things regarding the order of implementation. You don't have to specify any/all options if you are happy with the defaults, so you can do... //render a limited number of summarised posts + show featured image $featured = array('tag'=>'thumb', 'width'=>350, 'alt'=>'title'); $content = $blog->renderPosts("limit=5", true, $featured); echo $content; For featured blog_images In descending order, the order of image dimension manipulations for a featured image coming from blog_images as set in your $featuredImage options will be processed as follows (note: only one manipulation takes place! i.e., if, elseif, else...) (see what these mean in the Images docs) size = true AND width > 0 AND height > 0: $thumb = $image->size($x, $y);//where $x=stated width and $y=stated height width > 0: $thumb = $image->width($x);//where $x=stated width height > 0: $thumb = $image->height($y);//where $y=stated height No height AND no width stated: $thumb = $image;/i.e. original image output at original dimensions Also: alt: defaults to '$image->description'. If anything else is specified, then alt = $page->field where field is the given value in alt. e.g. if 'alt'=>'title', alt=$post->title tag: defaults to 'featured' but will take any string you specify in 'tag'=>'mytag'. For embedded images These are not subject to ProcessWire image methods. So there are no width, height manipulations If height and/or width > 0 is specified in $featuredImage options, these will be output in the img tag. In both cases, of course, you can still use CSS to control image dimensions and position. Some examples If you pass the following options to $featured in renderPosts("limit=5", true, $featured); /*will get first blog_images with tag='thumb'. Image width will be resized to 350, height proportionately calculated and post->title will be alt (i.e., post page's title). No size() applied since not specified so also height ignored. So no need to specify it here!*/ $featured = array('tag'=>'thumb', 'height' => 300, 'width'=>350, 'alt'=>'title'); /*same as above except image height resized to 300 and width auto calculated*/ $featured = array('tag'=>'thumb', 'height' => 300, 'alt'=>'title'); /*$image->size($x, $y) applied*/ $featured = array('tag'=>'thumb', size=>true, 'height' => 300, 'width'=>350, 'alt'=>'title'); /*no manipulations; original image output since no height and width specified with size. alt=$post->caption. So no need to specify size here!*/ $featured = array('tag'=>'thumb', size=>true, 'alt'=>'caption'); /*output first embedded image giving it height and width dimensions - In this case will only work if blog_images does not contain an image tagged 'featured'*/ $featured = array('height' => 300, 'width'=>350, 'alt'=>'title'); /*output first embedded image. In this case, doesn't matter if you tagged your blog_images or not*/ $featured = array('tag' => ''); Note: If you will be using blog_images to hold your featured image, you will have to enable use 'tags' in the field's settings (Detail's tab). I have decided not to enable this setting by default when Blog is installed since 'featured image' is an optional thing. This will not work with images embedded using Hanna Code since such will be output when page is rendered. To make things as light as possible, DOMDocument above looks in the blog_body html string retrieved from the database. If anybody has other thoughts please let me know, thanks. I will update Blog docs when this is committed to master. Thanks for testing. Screens (with custom CSS styles applied to img.post-small-featured-image) Float left Float right Top, no float

HI all, many thanks again for your replies. Just to sum up, the problem could be described as follows: After updating from 2.2.9 to 2.5.3 inheritance of rights between pages with different templates didn't work anymore. The issue is clearly associated with the update as this was the only change I made to a perfectly working system. I did not bother around very much with making new roles and associating my users to it as this is a live site. I tried, as Soma suggested, to save roles and users and all templates but this didn't work for me. I finally found a workaround by assigning access rights to the templates in question (instead of letting them inherit it) and this works now. However, it is not the intended behaviour of the system. Would you think I should file a bug?

Another solution could be to wrap a function around the include for the remote file. This way it gets opened in its own scope and doesn't override your $config object: function readRemoteConfig($pathToFile) { $config = new stdClass(); // it is enough to use a StandardObject here, - without that, PHP will raise a 'notice' I believe. include($pathToFile); return $config; } $remoteConf1 = readRemoteConfig("path/to/remote1/site/config.php"); $remoteConf2 = readRemoteConfig("path/to/remote2/site/config.php"); $remoteConf3 = readRemoteConfig("path/to/remote3/site/config.php"); // and your (local) $config isn't affected or touched in any way

Damn, there's too much to like in this thread....

Take a look at Soma's gist. It loops through all the fields of your page and displays a form. Then on Submit of the form it again loops through each field and saves the value. It also includes all styles and scripts that you need for your form to work on the frontend. This is working great for my frontend form. If you need help implementing it, let us know.

Great article Joss! And yes this is well worth funding (I'm sure Diogo will offer a free illustration for any PW donations ) Small typo = "flair/flare"

https://github.com/ryancramerdesign/ProcessWire/blob/576a5d30153f045daa94a136a6ba981650632b26/wire/core/WireArray.php#L833

That is were this module comes from. Sites where SEO aspects might not be the first priority. Also, couldn't PagePath History help here?

I have the exact same scenario and am using page field like sforsman suggested. To make your filters work you can use URL segments. Works like a charm.

@teppo: To be honest: I didn't think about that... Maybe I'm switching to create real fields so multilanguage will be easier, too. Have to think about it later today

@muzzer Check out Teppo's ProcessWire hooking article on this sort of thing and also look at the last two hooks added in the HelloWord example module. You'll see that Ryan's added the ability not only to externally inject new methods to Wire-derived classes but to inject new properties too.

@andi: thanks for the response! I took a look on the typo3 site and it looks like a good place for inspiration. I'll probably adapt some of the options there. But first I'm going to clean the current version and try to get multi language integrated (already tried it but it didn't work. So I have to try again )

Andi, nico has build an SEO tool not an encyclopedia.

Because PHP will assign an object pointer to a variable when trying to use the = operator to duplicate an object. It's passed by reference, so to say, though I don't like to define it like that. $config_tmp = $config; // $config_tmp points to $config echo $config_tmp->dbName . '<br>'; // says current_db_name include("../../site-xy/config.php"); // you overwrite $config here, but $config_tmp still points to it echo $config->dbName . '<br>'; // says remote_db_name, because you overwrote $config with the include $config = $config_tmp; // $config now points to $config_tmp, which still points at $config, which was overwritten with new values from the include ($config points to an object pointer that points to an object) echo $config->dbName . '<br>'; // says remote_db_name -----------> why? -- See above What you need to do is either clone $config, which will give you a shallow copy or serialize then deserialize the object to achieve a deep copy. ie $config_tmp = unserialize(serialize($config)); // Getting deep copy of $config OR $config_tmp = clone($config); // Getting shallow copy of $config echo $config_tmp->dbName . '<br/>'; // says current_db_name include("../../site-xy/config.php"); // original $config gets overwritten echo $config->dbName . '<br/>'; // says remote_db_name $config = $config_tmp; // $config is now pointing to the deep/shallow copy you made echo $config->dbName . '<br/>'; // should say current config_db_name now

Is this a multiple page field? In that case you would have to iterate it with a foreach or get the first one with first() <?php foreach($page->food_types as $ft) { echo $ft->title; } ?> or <?=$page->food_types->first()->title ?>

Overview Mobile Detect uses a lightweight PHP class Mobile_Detect for detecting mobile devices (including tablets). Installation 1a. Clone the module and place MobileDetect in your site/modules/ directory. [OR] 1b. Download it. git clone https://github.com/justonestep/processwire-mobiledetect.git your/path/site/modules/MobileDetect 2. Login to ProcessWire admin and click Modules. 3. Click "Check for new modules". 4. Click "install" next to the new SimpleContactForm module. Usage This Module extends $config and sets the following parameters: $config->mobileDetect = array( 'deviceType' => 'deviceType (phone, tablet or desktop)', 'browser' => 'mobile browser', 'operatingsystem' => 'mobile operatingsystem', 'device' => 'mobile device' ); You can access them where ever you want. See the example below: <body class="devicetype--<?php echo $config->mobileDetect->deviceType?>"> <body class="devicetype--{{config.mobileDetect.deviceType}}"> // twig Results in: <body class="devicetype--phone"> OR<body class="devicetype--tablet"> OR<body class="devicetype--desktop">

Upcoming Update: Blog version 2.1.1 (dev) Update as per request to allow user to control position of featured image - either above post-headline or below post-body. Default is, if present, output featured image below post-body. To output a featured image above the post-headline, include the 'key'=>'value' pair 'position'=>'above' in the $featuredImage options array, .e.g. $featured = array('tag'=>'thumb', 'width'=>550, 'position'=>'above'); echo $blog->renderPosts("limit=5", true, $featured); For new readers, also refer to the original Blog 2.1.0 post above. Feature available in the dev branch for testing, thanks. Screenshot

Yes ; isn't that what this module is already doing? No ......Here's why... {also see the G thing...}

Thanks to both for your help and answers... wish I could mark both as the solved post Cheers guys!

I've never watched Toy Story, but I was always wondering what Debian will do if they run out of characters to name the release after … Personally, I don't really care for target audiences or if they'll find code names appealing or off-putting. Code names IMHO are for users and developers, not for suits. I don't think anyone has ever considered not using a Debian server because the OS is called “Wheezy”. I do, however, think that this should ultimately be Ryan's call.

Awww, sweet. Never did get my hands round that middle bass part though.

All good here. Didn't have any trouble with MAMP, apparently all you have to do is upgrade it also.

Yeah, but your option is way nicer once you get to more than a couple of options like this

You are not using a PW selector. This needs to be in PHP syntax: if($page->template->name == 'home'|| $page->template->name == 'project' || $page->template->name == 'projects' || $page->template->name == 'posts' || $page->template->name == 'partners'){ But maybe instead you could see if the $page->sidebar actually exists. Maybe that won't work in your scenario, but thought I should mention it just in case.

At lightning.pw, we use elements as subdomain names (also I heard, that one or two users spotted some sort of "wire" domains) @Joss: ProcessWire Lemon sounds AWESOME At general, I like the idea of using codenames and i find the Architects' names being the best. It is a nice callback to ProcessWire's origin and most of them sound cool.

Didn't know that, Ryan has pretty great technical solution there! I still stick with my opinion here: better to keep url change always clear decision. Avoid unnecessary redirects and url changes vs. some "/sample-page/" url from cheating at the beginning of the project

Thanks for your thoughts Antti. As for the 20 000 pages recursion writing to the database - admittedly I haven't studied the PagePathHistory module, but from what I have seen, it only stores the path to the parent page that was actually changed, eg news with the id for the page which is now named latest-news. It doesn't store rows for each of the child pages. Or sorry if I am missing your point? Ajax polling is definitely a good point, although I don't usually have pages that are called via ajax editable by non-superusers, but I guess this could definitely be an issue in some cases. I like to plan too, but clients often don't

Thank you for the module. Just one suggestion: In terms of human readable URLs, wouldn't it be better to attach the time as a Datetime string like "2014-10-21-16-04-33" rather than the unix timestamp?

First a few questions. How probable is it that the VPN is down? When the VPN is down, how long is it usually down? Approximately how many writes are there during the day in the branch-offices? How probable is it that there will be more than 9 offices? Also I'm curious, why have you selected SymmetricDS over Tungsten Replicator? I don't see how this would be a problem when you are using auto_increment_increment and auto_increment_offset. You might have read this but it's a good article nonetheless: http://scale-out-blog.blogspot.fi/2012/04/if-you-must-deploy-multi-master.html

Thanks Kongondo. Blog module is just getting better and better. BTW I've had the issue in the past where I've needed a "featured image" with each post. Using your older Blog Module, I've just told editors that the first image in the images field will be the featured one and it's worked perfectly. They know they can reorder images as required so have very few probs that way.

Yes, you can call $pages->imagefield->first()->url or $pages->imagefield->eq(n)->url in separate spots in your template, but that doesn't mean it is easiest in all situations. Typically using one images field with support for multiple images is good for sliders/carousels and image galleries, and for insertion into body text, but if you are talking about wanting to add a specific sidebar image and a main article image or similar setup, I would go with two separate image fields set to support only one image. It really depends on your scenario and what works best for you and your clients.

It all depends who you are aiming the names at: If it is Developers, then scientists might work, though I think engineers is probably closer to the DEV way of thinking If it is designers, then it should be the influential designers/artists/architects throughout history. If it is at business decision makers, then maybe it should be using names of great economists and business leaders throughout history Personally, I always thought the trouble with names was that I could never remember which was the current and which was the old one, and if the name was not familiar it did not stick in my head anyway. I like numbers, though you can have fun and add colours or something to give it lift. ProcessWire 2.5 Blue ProcessWire 2.6 Lemon (possible a bad idea) ProcessWire 2.7 Red ProcessWire 2.8 Jade

This is not a problem for ProcessWire. There would be multiple ways of implementing that. Check this tutorial for an example https://processwire.com/talk/topic/7548-dual-url-structure-for-categorized-content

There has definitely been an influx of new very talented coders in the PW world lately. I for one am thankful and am excited about this occurrence. Keep up the good quality work.

Hello again! We've just updated Ratings to Version 1.1, which includes a simpler, more unified API. You can access all API methods via the ratings property. Examples: $page->ratings->add(4); $page->ratings->average; // => 4.4 $page->ratings->count; // => 12 The changes should appear soon in the ProcessWire modules directory. Please check out our GitHub repository for more details.

You can use a WireArray and fill it with image objects from pages. Then get a random count from that WireArray. It's also in the cheatsheet. // new WireArray object for storing images $images = new WireArray(); // we find all pages using a specific template that have at least 1 or more images. // assumes the image field is named "myimages". If we deal with really lots of pages/images, consider using a limit to avoid performance problems $pa = $pages->find("myimages.count>0, template=basic-page, sort=random, limit=10"); // loop all found pages and import the images to the $images object foreach($pa as $p){ $images->import($p->myimages); } // output 4 random images from the wire array foreach($images->getRandom(4) as $img){ echo "<img src='{$img->url}'/><br/>"; } Reading again, and looking at Ryans code, it does pretty much the same, just little different way. Think about it again... Is there really any difference ? From: get ALL images from ALL pages and choose 6 random from them. To: get randomly 6 pages from ALL pages and choose 1 randomly from each page. I don't see really a difference, only that the second is far better and the way to go, because you limit the find for pages in the first place. Getting all images from all pages could create problems and not so scalable.

I would suggest grabbing one randomly from each page: $entries = $pages->find("template=gallery_entry, sort=random, images.count>0, limit=6"); $images = array(); foreach($entries as $entry) { $images[] = $entry->images->getRandom(); } foreach($images as $image) { $img = $image->size(80,60); echo "<a href='/albums/'><img src='{$img->url}' alt='Latest photos' /></a>"; }