Leaderboard

It would just depend on what's being worked on. I generally don't push stuff to GitHub until I know it's solid. If working on something that's going to take a couple weeks to get to that point, then I'll avoid having it appear on GitHub because it wouldn't be ready. Since plans for 2017 include a focus on some things that may go beyond the usual weekly timeline focus, I'd say that weekly activity on the GH repo would reduce a lot when these things are being developed. Of course, activity on the core code wouldn't be reduced at all (likely increased), but the frequency of commits that appear on GitHub would be reduced. Plans are to keep it roughly as-is. But since it's now ~130 posts, it's time to add a few more things like categories, related posts, next/prev post links, etc. I also want to upgrade it to be more guest-author friendly, so that it includes authorship information like we have in the tutorials (example).

In a rush, so no help on the selector, but here is the info on has_parent now supporting multiple values: https://processwire.com/blog/posts/processwire-core-and-profields-updates-2.5.22/#has_parent-selectors-now-support-multi-value

The slightly longer version... where (200,200) means an image width 200px in width and height, croped from the center. (200,0) would result in an image 200px in width and whatever results in the height A good starting point would be the doc to the fieldtype images

$child->Image->url;

wow, i totally missed that! thank you! ok, i see..

I might be wrong but as I remember has_parent only works with one value. Edit: the docs says "Note however that at present, you can only specify one page at a time here (meaning no has_parent=1|2|3)."

I am glad to present our recent website. It was made, of course, with Processwire and this is the first time we use this CMS in our company. The website (in French only) is aimed to gather ski results from four youth ski clubs (our clients). The administrators needed something easy to use and be able to import XML ski results after a race. Those results are divided between ages (four categories, girls and boys), each ski category having its own rules for distribute points and ranking. The administrators wanted also a place where representatives of each club could post photos (elite team only). Processwire was the perfect candidate for this site which is fully mobile. Race calendar and results (click on this archived season to see the whole process since the present season has not yet begun as the writing of this post.) Annual ranking Documents (use of hanna code to place and identify type of document) Photo albums Elite clubs

Sounds like you found a good solution. Other potential solutions are reading and re-writing the options from your render() method, or override the renderOptions() method, or just modify the protected properties inherited from InputfieldSelect (like $this->options or $this->optionAttributes).

If you use a renderReady() method, here's what the definition looks like: https://github.com/processwire/processwire/blob/master/wire/core/Inputfield.php#L1009 Remember to end by calling the parent::renderReady() method as well: public function renderReady(Inputfield $parent = null, $renderValueMode = false) { // perform any needed initialization here return parent::renderReady($parent, $renderValueMode); }

Hi! If you have an array of images, try this: $child->image->first()->url $child->image->first()->size(200,200)->url

Yes, that's true that you can't use $page inside a function, but the other thing here is that you already have wire('page') - there is no need to get the page from pages again, so this should be fine: $this->set('successMessage', '<h2 class="enviado-ok">' . wire('page')->mensaje_form_enviado .'</h2>');

Welcome to the forums and ProcessWire @Emile. You probably know this already, but since you are new, I just want to confirm that you edited /site/config.php and NOT /wire/config.php ? .

I can only concur that this has been a great year. It was nearly impossible not to get infected by the momentum of PW's development. Love (that's an understatement) the JS $pages API plan, and the pages export/import function could even be a solid base for native staging support, just by hooking into the proper PW actions and filling a staging actions table. You're absolutely right, @apeisa, PW is much more than just a brilliant website platform. Our intranet site really does some "heavy lifting", consolidating information from the ERP system, the DMS, personnel and operational time keeping, financial accounting and a few proprietary databases. That way, it also serves as the middleware for a big, distributed test run database. Like Sense, it drives a few chained workflows, e.g. for bridging the feedback gap between dunning proposals and our sales managers. All our intra-company course scheduling/booking runs on PW too, including supervisor approval, and it was surprisingly easy to implement. HR was over the moon with PW's ease of use. For 2017, we're planning a site that provides our customers with all the publicly available documentation for the machines and plant parts we sold them, requiring just a QR code scan on their side. Setting up a working (UIKit styled, multilingual) prototype only took me a few hours and really impressed our sales guys If 2017 is going to be anything like this year, it's going to be a blast. Thank you @ryan! A happy, healthy and inventive new year to everyone!

Great blog post Ryan, thank you! Great year behind and even better coming! What comes weekly news, I think maybe @teppo and PW Weekly could report interesting new stuff from dev branch - instead of full blog post by @ryan each week? Also I think what would really help PW as a community project is that modularity would be more easily seen from code repositories also. I mean separation of /wire/ from rest of the stuff, keeping admin as own project and making several core modules as their own projects (although they could be "essentials" that would always be installed with ProcessWIre). What comes to Avoine, I hope I found time to write case story about how we use ProcessWire as backend solution to our member register platform Avoine Sense. Sense was released early 2016 and it already hosts about 10 member registers that together hold about 150 000 members. Feature-wise Sense already has newsletters, custom reporting tool, invoicing, model based templates/fields, background jobs, client specific procedures build by chaining actions (ie. create excel, connect ftp, deliver file and finally send sms to admin), full read/write REST API with Oauth2 authentication, mobile application, embeddable login/edit forms etc... ProcessWire has been amazing platform for our application development (currently we have 4-5 developers working on it). I strongly encourage that you all consider ProcessWire as a viable alternative for serious application development also. It is perfect platform for building dynamic websites, but it is also pretty brilliant platform for application development!

You could also shorten this... $config->urls->admin."page/edit/?id=".$page->id ...to this (available since PW 2.5 I think) $page->editURL, Welcome to the forums

@Juergen Sorry for being off-topic, but if you like UIkit, you should look out for UIkit 3. I am excited.

I was just reading this post on how to make breadcrumbs in ExpressionEngine (http://bit.ly/hello_crumbly) and how you basically have to resort to a plugin to do it for you. It reminded me of some of the problems I had with EE when I was trying to use it and develop in it awhile back. One being that URLs aren't a primary/unique key to a page, natively in the system. Imagine ProcessWire with only it's root level pages and url segments, and that gives you an approximation of what you have to deal with in EE. I'm not saying it's wrong, but it's a different approach, and one that I found frustrating to work with. The post also made me realize I didn't have anything on the site demonstrating how you might make a breadcrumb trail (other than in the default site profile). It's really a simple thing (at least, relative to EE), so figured I'd post here. : <?php foreach($page->parents() as $parent) { echo "<a href='{$parent->url}'>{$parent->title}</a> "; } You may want to output those as list items or add some >> signs between items, but as far as code goes, the above is all there is to it. What it's doing is just cycling through the current page's parents till it reaches the homepage. Lets say that you also wanted to include the current page in your breadcrumb trail (which is probably redundant, but some sites do it). What you'd do is just append it to the list of parents that gets cycled through: <?php foreach($page->parents()->append($page) as $parent) { echo "<a href='{$parent->url}'>{$parent->title}</a> "; } The reason this is so simple is because every page is anchored to a specific URL and those URLs are representative of the site's actual structure. Pages in PW are actually uniform resource locators (URLs) whether on the front end or the back end. Because of that, there's no guesswork or interpretation to be done. In EE and Drupal (as examples) that data does not natively live at a specific URL. Instead that data is off in a separate container and the ultimate URL (or URLs plural) where it lives–and will be presented by default–are not as cut and dry. Yes, you can install plugins or go through strange taxonomic/channelistic/cryptic trials to approximate the behavior in other systems. And yes you can use url segments and pull/render any other pages you want in ProcessWire according to your own needs. But I'm talking about the fundamental and core system differences. This difference goes far beyond simplicity of generating breadcrumbs–it is a factor that translates to simplicity throughout the API.

This will overwrite also existing classes. If you want them to stay $field->attr("class" , $field->attr("class") . "myclass");