Leaderboard

Soma, Pete, I stand corrected In any case, it's clear that Cufón is not a good option anymore now that @font-face support is broad enough. Apart from the inability to select text, enlarge it without pixelating, Cufón is slow to render and routinely suffers from FOUT (Flash of Unstyled Content) without resorting to hacks.

I've been working for some time on an updated version to functionality of the cheatsheet and have commited it now. All code and functionality, no content changes. removed table layout and added the excellent Masonry/Istope js for block layout and filtering added setting for column count so you can change it to your best fit in the toolbar improved live search, especially in Firefox (which wasn't really working before) now sections not containing any filter results will be hidden (not get in the way anymore) These changes also will help adding more content to the sheet. Preparing to launch the rocket! Enjoy.

We'll use this thread to discuss PW 2.3 features as they are being worked on. I've just added one of the first components. This is the "Page Path History" module. It's now in the PW core as a beta module (uninstalled by default). If you are interested in helping to test, just install the module from Admin > Modules > Page > Page Path History (after doing 'Check for new Modules'). The Page Path History module keeps track of the previous URLs for any pages that have been moved or renamed. It then sets up automatic redirects (301, permanent) to ensure the old URLs redirect to the new ones. This is best demonstrated by a few examples: Lets say you had the page /about/contact/ and you moved it to /contact/. With the Page Path History module installed, anyone accessing /about/contact/ will get redirected to /contact/. You had a page called /our-products/ and you renamed it to be /products/. Any accesses to /our-products/ will now get redirected to /products/. Those are simple examples, but this module can handle more complex situations too: Lets say you had the page /our-products/furniture/whoopie-cushion/ and you did like in the previous example and renamed /our-products/ to be /products/. The /our-products/furniture/whoopie-cushion/ URL will now redirect to /products/furniture/whoopie-cushion/ Later on you decide to rename /products/ to just /inventory/. All the /our-products/ and /products/ URLs will continue to work with redirects. You decide that whoopie-cushion really belongs in /services/ rather than /inventory/, so you drag it to /services/whoopie-cushion/. It's old URL in /inventory/furniture/whoopie-cushion/ redirects to it's new URL. TL;DR (am I doing this right) -- you can move or rename any pages and all the old URLs will redirect to the new, automated behind the scenes, without any thinking on your part.

Updated to 2.2.2, the problem remains. I tried to delete all those repeaters and to recreate them; on my page I have a first repeater sliders and a second features which was created by cloning sliders. If I add a couple sliders items and save, the page will now have the same number of features items :'-( EDIT: oh Ryan, you replied while I was typing this. That's fine, I will manually clone my repeater. Thanks

It depends on whether you are talking about 'autoload' modules or not. If the dependent module is 'autoload' and the dependency module isn't, then your dependent module can just load the dependency in it's init() or ready(), like this: public function init() { $dependency = $this->modules->get('YourDependencyModule'); } If the dependency module is 'autoload' and the dependent module isn't, then then dependent module can safely assume the dependency is already loaded. If both of them are 'autoload' then you don't necessarily know which will get loaded first. But by the time either module's ready() function is called, you know that both have been loaded: public function ready() { // safe to assume all autoload modules are loaded and have had their init() called } If the dependent actually extends the dependency (like one class extending another), or has code that needs stuff defined from the dependency before PHP will even parse it, then you need the dependency to have been included as a file first (like you'd expect anywhere else in PHP). As long as you reference the dependency class name in some form, it should trigger PW's class loader to find and include the file. Something like a "Dependent extends Dependency" class declaration should do that, as should a function call like: Dependency::getModuleInfo(). If you find that still doesn't do it, you can also try including it manually. But use the "once" version, i.e. include_once($file); or require_once($file). However, I don't think you'll have to go as far as doing this manual inclusion. Install Dependency Because load order dependencies don't usually require any intervention on your part, we usually think of module dependencies as being install related. ProcessWire has some things to help you in this area. You can specify this in your getModuleInfo() method: static public function getModuleInfo() { return array( 'title' => 'Module title', 'summary' => 'What the module does', 'version' => 100, 'autoload' => true, 'singular' => true, 'requires' => array('YourDependencyModule') // SEE THIS LINE } Here are all the details about module dependencies.

Also wanted to mention that in 2.2 a "push-to-top" and "push-to-bottom" option was added for images. Hover over any image in a list and you'll see them as up/down arrows. Click the up arrow and it pushes it to be the first image at the top. Click the down arrow and it pushes it to the bottom. This makes your client's sorting scenario a lot easier, especially when dealing with lots of images.

Two useful bookmarklets for testing responsive designs: http://responsive.victorcoulon.fr/ http://www.benjaminkeen.com/open-source-projects/smaller-projects/responsive-design-bookmarklet/

That's where I was getting PNG from jacmaes, although it's not obvious unless you know where to look. You can also save the resulting image as a PNG if you wanted to. I remember back in the good old days where I auto-generated PNG article titles using PHP and custom fonts before any other options were available - those were the days

"The emulator is super simple to install and lets you do serious mobile development from your desktop." So far none of the emulated devices shows/works the same as with the real device. Some more or less. I wouldn't rely on emulators at all for serious developement.

Clever module and I love the simplicity of the implementation: https://github.com/r...hHistory.module tsd: it doesn't touch .htaccess at all. If processwire throws 404 it then checks if there has been page in that path. If has, then it checks if that page is still live somewhere and is viewable by current user. If it is, then it does 301 redirect there.

That's very sincere of you. You have such an open mind when it comes to solving problems. Great work and I think SiNNuT and I and potentially others have some food for thought right now. In my case there were no riders, but Korfball players for one club. It might be interesting to follow their progression throught a career. This would be next to impossible in Textpattern, but I thought about it a lot. Your thoughts should work too. I never even started the project because I was afraid of the potential pitfalls I might run into. But this was before my PW days, so I might give it another go. Thanks again.

I appreciate the interest. There isn't currently a donation capability here right now, though I hope to figure it out this year. Since I incorporated my business a long time ago (2003), ProcessWire is technically built by RCD (Ryan Cramer Design, LLC), so not really sure how to handle donations given that it's a corporation. I think I just need to do more reading, but I find the material hard to understand, so it's slow reading. Probably what I will do is move ProcessWire to it's own legal entity (non-profit entity or foundation if possible). And that should make it straightforward to accept donations as well as make them tax-deductible for the people that donate. But until then, the best way you can donate to the project is staying involved and active, and spreading the word online when and where possible. I think that are a lot of people that may benefit from ProcessWire that don't yet know about it.

Almost anything involving output of markup is not an ideal candidate for a core module (/wire/modules/), but always a great candidate for add-on modules (/site/modules/). The intention is that the PW core stays as markup independent as possible.