Leaderboard

Hi all! I have just created a proof-of-concept Module here: https://github.com/U...ocesswire-views. The main idea was started by me in this topic: http://processwire.c...age/#entry21257 The aim of this module is to extend the number of files associated of a specific Template. For example: if the template name is "page", the file associated is "page.php". With Views we can have others visualization of the same Template named in this way: view_name1-page.php view_name2-page.php | | | view_nameN-page.php Also you can test your view (useful when developing...) in this way: example: http://example.com/great-page/?view=fullscreen where "fullscreen" is the name of the view. IMPORTANT: Since i'm still learning how to make modules, the module works with a TextField called "view" (where is stored the name of the view), and you must create it manually. Maybe in the next few days i will make the automatic creation of the field and some other functionalities. Any Feedback is appreciated! USSliberty

So, besides little bughunting, I was thinking what would be the best thing to provide. And, I decided to focus on content creators. Check this super-cool thing out (you might want to go to youtube to see HighRes )

My english isn't so good, so I can't express my thoughts (and requests ). I love ProcessWire, the forum and the contribution that Ryan and the PW gurus give to the community. I hope I will be able to return this in future. Thank you all, guys.

Hey PW, I am only a starting developer and I am still in school and my experience with processwire is quite small but recently I've created my own module for Processwire and I kind of had to ask and copy a lot from other sources, now I want to create a small walk through tutorial for people with the same lack of knowledge as me And as a guide for myselfs in the future 1) Setting up the file. Okay, so we start of by making a new document in the Module root folder and call it Harmster.module for this example, we dont need to add the .php extension. Now every module in Processwire needs to extends the classes and methods from Processwire itselfs so we start off by typing class Harmster extends Process{ } You can also extend WireData, I don't really understand the difference but both work for me A module contains 2 standart classes, init() and getModuleInfo() init() This is kind of, or the same as a __construct() method, this always executes and is executed almost at creation. getModuleInfo() This is a method that is used to show the information in the Processwire CMS. We both need to add these to our fresh class like following: class Harmster extends WireData { public static function getModuleInfo() { return array( 'title' => 'Harmster', 'version' => 100, 'summary' => 'Harmster module' 'singular' => true, ); } public function init() { $this->setFuel("harmster", $this); } This is where I, as a starting developer, get really excited about this little code in the init() method $this->setFuel("harmster", $this); Basically creates your class in every template you are going to use and it is callable by $harmster Woah! awesome right! Now this is where I got stuck on, I the user to configure some options in the module :\ hmm... Well I just went asking on the forums and the super nice community of PW came to help me, Wanze in this case (no emoticon because its not allowed) (Check it for yourselfs, http://processwire.c...lds-for-module/) And basically you need to implement some methods from an another object, you should replace this, class Harmster extends WireData implements Module with class Harmster extends Process implements Module, ConfigurableModule But when you add that and try to use your module you'll see you get an error, we need to add one more method to the class called getModuleConfigInputfields add static public function getModuleConfigInputfields(array $data) { } 2) Adding a configurable and usable textbox But now you want to add some input fields, now this is pretty hmm complicated For a simple textbox you put this inside the method you just made: $modules = Wire::getFuel('modules'); $fields = new InputfieldWrapper(); $field = $modules->get("InputfieldText"); $field->attr('name+id', ''some_text_field_saved_name''); $field->attr('value', $data['some_text_field_saved_name']); $field->label = "Hamsters rule!"; $field->description = 'Enter a nice sentance here if you like hamsters'; $fields->append($field); Now you've created a input field and you can use it with $this->get(''some_text_field_saved_name''); in all your methods in this class (no emoticon because its not allowed) If you're lazy Now what you've created is a configurable module, heres a I am lazy and i want to pastey (no emoticon because its not allowed) class Harmster extends Process implements Module, ConfigurableModule { public static function getModuleInfo() { return array( 'title' => 'Harmster', 'version' => 001, 'summary' => '', 'href' => '', 'singular' => true, 'autoload' => true, ); } public function init() { $this->fuel->set("harmster", $this); } static public function getModuleConfigInputfields(array $data) { } } Now if you want to add a overview page, much like the setup, pages, acces and module tab in Processwire CMS default you can easily do this by adding 2 new methods in your class, install and uninstall 3) Creating your install and uninstall So you want to get a nice overview for your module now eh? Well we can do that because Processwire is awesome like that I did this for my module Now, we need to add 2 methods to our class, ___install and ___uninstall (yes, 3 underscores) So add this to your class: public function ___install() { } public function ___uninstall() { } I think that these are kind of self explaing, the one method gets executed when the user installs the module and the other one gets executed when the user deinstalls the module. Now we want to add a page to PW CMS, but how (no emoticon because its not allowed) Thats actually really easy, $page = $this->pages->get('template=admin,name='.self::PAGE_NAME); if (!$page->id) { $page = new Page(); $page->template = $this->templates->get('admin'); $page->parent = $this->pages->get($this->config->adminRootPageID); $page->title = 'MailChimp'; $page->name = self::PAGE_NAME; $page->process = $this; $page->save(); } This is how you install a page, notice that we name the page to self::PAGE_NAME therefor you want to add const PAGE_NAME = 'harmster-module'; with the name of your module BUT BUT now everyone can look in to this module D:< i dont want that! Ofcourse you dont want that. Clients are famous for breaking everything where they put their hands on, so we need to create permissions! Now the way you make permissions is just genius and so easy, you just add this to your ___install method, $permission = $this->permissions->get(self::PERMISSION_NAME); if (!$permission->id) { $p = new Permission(); $p->name = self::PERMISSION_NAME; $p->title = $this->_('View Harmster Page statistics and synchronize pages with lists'); $p->save(); } And you create a permission constant just like PAGE_NAME like this const PERMISSION_NAME = 'hr-view'; And of course you can create more permissions, just genius! Now what our install method should look like is this: public function ___install() { $page = $this->pages->get('template=admin,name='.self::PAGE_NAME); if (!$page->id) { $page = new Page(); $page->template = $this->templates->get('admin'); $page->parent = $this->pages->get($this->config->adminRootPageID); $page->title = 'Harmster'; $page->name = self::PAGE_NAME; $page->process = $this; $page->save(); } $permission = $this->permissions->get(self::PERMISSION_NAME); if (!$permission->id) { $p = new Permission(); $p->name = self::PERMISSION_NAME; $p->title = $this->_('View Harmster Page statistics and synchronize pages with lists'); $p->save(); } } This will set a module page up for you And we create an uninstall method, this basicly reverts your installed permissions and pages. public function ___uninstall() { $permission = $this->permissions->get(self::PERMISSION_NAME); if ($permission->id) { $permission->delete(); } $page = $this->pages->get('template=admin, name='.self::PAGE_NAME); if ($page->id) { $page->delete(); } } Now you are might be wondering, how do i get to display content in my page :S Well, I kinda stole this from other modules and it does work, but I am open for suggestions. the method ___execute gets executed when you click on your page in the PWCMS. What i wrote in there is public function ___execute() { return $this->_renderInterface(); } and in renderInterface() i put the next code: private function _renderInterface() { $this->setFuel('processHeadline', 'MailChimp synchronize tool'); $form = $this->modules->get('InputfieldForm'); $form->attr('id','ga_form'); $wrapper_audience = new InputfieldWrapper(); $field = $this->modules->get("InputfieldMarkup"); $field->label = $this->_("Gebruikers"); $field->columnWidth = 100; $members = $this->list_members($this->get_apikey()); $html = "<table class='AdminDataTable AdminDataList AdminDataTableSortable'>"; foreach($members['data'] as $member) { $html .= "<tr><td>" . $member['email'] . "</td><td>" . $member['timestamp'] . "</td></tr>"; } $html .= "</table>"; $field->attr('value',$html); $wrapper_audience->append($field); $form->append($wrapper_audience); return $form->render(); } Bascily you create a form and you render the form and that displays it for you, just play around with it for a bit and you'll get into it, as i am still getting into it. I am lazy, here a copy, pastey (no emoticon because its not allowed) <?php class Harmster extends Process implements Module, ConfigurableModule { const PAGE_NAME = 'harmster-module'; const PERMISSION_NAME = 'hr-view'; public static function getModuleInfo() { return array( 'title' => 'Harmster', 'version' => 001, 'summary' => '', 'href' => '', 'singular' => true, 'autoload' => true, ); } public function init() { $this->fuel->set("harmster", $this); } static public function getModuleConfigInputfields(array $data) { } public function ___install() { $page = $this->pages->get('template=admin,name='.self::PAGE_NAME); if (!$page->id) { $page = new Page(); $page->template = $this->templates->get('admin'); $page->parent = $this->pages->get($this->config->adminRootPageID); $page->title = 'Harmster'; $page->name = self::PAGE_NAME; $page->process = $this; $page->save(); } $permission = $this->permissions->get(self::PERMISSION_NAME); if (!$permission->id) { $p = new Permission(); $p->name = self::PERMISSION_NAME; $p->title = $this->_('View Harmster Page statistics and synchronize pages with lists'); $p->save(); } } public function ___uninstall() { $permission = $this->permissions->get(self::PERMISSION_NAME); if ($permission->id) { $permission->delete(); } $page = $this->pages->get('template=admin, name='.self::PAGE_NAME); if ($page->id) { $page->delete(); } } public function ___execute() { return $this->_renderInterface(); } private function _renderInterface() { $this->setFuel('processHeadline', 'MailChimp synchronize tool'); $form = $this->modules->get('InputfieldForm'); $form->attr('id','ga_form'); $wrapper_audience = new InputfieldWrapper(); $field = $this->modules->get("InputfieldMarkup"); $field->label = $this->_("Gebruikers"); $field->columnWidth = 100; $members = $this->list_members($this->get_apikey()); $html = "<table class='AdminDataTable AdminDataList AdminDataTableSortable'>"; foreach($members['data'] as $member) { $html .= "<tr><td>" . $member['email'] . "</td><td>" . $member['timestamp'] . "</td></tr>"; } $html .= "</table>"; $field->attr('value',$html); $wrapper_audience->append($field); $form->append($wrapper_audience); return $form->render(); } } I'll update this tutorial in the near future as i am still working my way up (no emoticon because its not allowed) Aww, i get an error when i save it, thats not nice. Thanks for reading (no emoticon because its not allowed)EDIT Updating this tutorial very soon, its horrible and incorrect

I want to say thanks to all people in the forums for being here and make this place so special and a great place to be. There's some spirit and drive going, I think many other CMS forums can only dream of. It's still small and the quality of people and their support to help in the forums always amazes me. Even newcomers help other newcomers in a manner it's quite unique I think. Not saying there's might other places that are the same, but I don't know of any. Thanks for the nice experience to all of you! Then the biggest thanks would go to Ryan our "Man on the Wire", always sharp and considered helpful, with brilliant ideas and execution. You build something very special here and while maybe some think it's not "sexy" enough, they don't know what's under the hood. I think people are really excited to get direct responses from you and this is what makes them feel at home, which ignited some friendly fire and spread all over the place. Quo vadis? This is for now and I really wonder how it will be when the forums grows to a place, where I hardly will be able to catch up with new posts. Every other day I wonder how long Ryan will still be able to do so for every question in the forum. Don't know how you do it but you do. So then where will ProcessWire be in a couple years from now? How far will this forum grow? Will there be lot's of PW sites spreading across the web and sharing places as with other big CMS'? Hardly think about it but I think it could very well happen. What could the PW web be? How many modules will there be and quantity > quality... While at it, Clouds! I can't hear stand it anymore, STILL we have moving clouds in the new ProcessWire website!!! Hope people don't think we go PW Cloud? Also I would love a horde of crazy new core php developers that help making crazy new stuff with this CMS/CMF. No I'm not drunk but after that post I'm wired. Keep it up, stay healthy and spread the word "ProcessWire". Peace. ( Ahhh, I reached 2000 posts and I didn't even notice yet! Well never used to post that much in a forum ever. Well mostly just BS nobody wants to hear heh )

Hello folks, The next release of textile (v2.5) is going to see some major changes to the codebase and a few minor additions to its abilities to handle text. The changes outlined here are not yet committed to the dev branch of netcaver/textile but (Now committed) I want to post about this in advance so any developers here can get a feel for what will be changing and see if it impacts them (to track what is already committed to the dev branch for v2.5 you check the changelog.) As I'll be taking over responsibility for maintaining the textile text formatters with this release, I'll also take care of making sure these code changes don't impact end users of the textile in PW. However: if there any devs reading this who use textile in other work they might be interested in the rest of this. To facilitate textile’s uptake in other projects & to make it plain easier to read, I'm moving the code towards PSR-2 compatibility. Although I don't necessarily agree with everything in the PSR-2 standard, I will be adopting it for textile because... textile has used no coding standard to date and has had many contributors who have all used different styles & consequently the coding style (or lack of it) reflects this and needs some sanity restored to it. It gives people who may contribute to textile a standard to work to. I have been advised that a minimum of PSR-1 compatibility is required for textile's uptake in at least one other CMS. So how might these changes bite your installation? Here's a few ways... First potential problem: Are you overriding textile's defines to customize something? As PSR-1 (needed for PSR-2) doesn't particularly like code declarations & side effects (such as the #defines that pepper textile) in the same file, I need to know what use, if any, folks are making of the existing txt_ defines listed here as they will be going. If you are using them, you will need to start calling a new method setSymbol('name', 'value') prior to calling TextileThis() or TextileRestricted() and drop the defines as textile will no longer be using them at all. NB. the 'name' to pass into setSymbol() is as shown in the link above without the leading 'txt_' which is no longer needed as the names will no longer be in global scope. If you are using textile in exactly its default configuration with respect to defines there is nothing to worry about so far. Next: Using a define called 'hu' to make all relative image paths absolute. This is only likely to impact the use of textile in Textpattern CMS (it's original parent project.) Textpattern CMS uses a define called 'hu' to point to its root path and if textile finds a define called hu it uses that to prefix all root-relative image paths turning them into absolute paths. Now that textile is breaking free from its Textpattern CMS heritage, I think it's time to break this hidden coupling between the two and instead replace it with a generic (and explicit) setRelativeImagePrefix() method, allowing other projects to use relative image path prefixing if they need to without resorting to using the 'hu' define and without the possibility of a name conflict if they already happen to be using a define called 'hu' for something else. If your project doesn't use any define called 'hu' the above won't be a problem for you. Finally: Still using PHP4? I thought not, but I have to cover this anyway. Next up is PSR-2's requirement for explicit visibility on all properties and methods. As textile comes from a PHP4 heritage it has never had these. A quick look at my stats for PHP versions across hosts show that ~79% of hosts run PHP of some kind and that ~76% are PHP5 or better. Needless to say, PHP4 support is going. But even if you are running PHP5+ this change to the textile codebase will bite you if... you are calling any methods other than the constructor method, TextileThis() and TextileRestricted(). you are accessing any of the class properties. These will all become either protected or private and most will have no set or get methods. I figure that for most projects using textile there will be no issues but please let me know if you are going to get bitten by any of the above and if you know of other devs who use textile in their projects, please give them a heads-up.

First pw site... http://www.stokar.com/ composer's management agency. Processwire was great for this!; took on every challenge and request the client had with ease. Thanks to Ryan, and to everyone on the forum - it was an essential resource for working out all of the code to make this site work. -marc

Welcome henriette. There's several ways to archive what you want. Your ideas are on the right track, you definately want to create some "/footer/" page where you could enter the content for your footer then output the content of that page. http://processwire.c...-settings-page/ Single page approach: If you create a template "footer" and in the php file you just would output the markup and data of the page. You can make this page "hidden" to not show up in navigation. Then in your main template, where you would include you just render the "/footer/" page like this. echo $pages->get("/footer/")->render(); and the footer page template would be this (just example. <div id="footer"> <?php echo "<h3>$page->title</h3>"; echo $page->body; ?> </div> Subpages or repeater approach: You could use repeaters or just subpages to create the 3 blocks. Repeater module is a great way to "repeat" a set of fields. It is not installed by default. See infos here: http://modules.proce...dtype-repeater/ If using subpages you would create children pages under maybe a page "/footer/". Then output them like this. $blocks = $pages->get("/footer/")->children('sort=sort'); foreach($blocks as $block) echo $block->render(); If using repeater, it would be slightly different, but the repeater field is like a field that holds pages, but since you can't use render you'd have to output markup too. If repeater field is named "footer_blocks" with title and body field inside you'd do it like the following: $footer = $pages->get("/footer/"); foreach($footer->footer_blocks as $block) { echo "<h3>$block->title</h3>"; echo "<div class='footer-body'>$block->body</div>"; }

Hi Henriette I have done a similar thing on a site I am currently working on. There are a lot of ways you can do this. Here is a very basic version: Create the fields for your three blocks - call them Block Title 1, 2 & 3 and Block Body 1, 2 and 3. Create a template that includes these fields. Now create a new page Called "My front Blocks" (I am being really predictable here) and use your template. Go to Settings on the page and make it hidden (it should be published, however). Now fill in your information. That has given you the block content. You now need to call it into your footer. In each position You need to call in the fields from My Front Blocks: <?=$pages->get("/my-front-blocks/")->block_title_1 ?> <?=$pages->get("/my-front-blocks/")->block_body_1 ?> And so on. I leave the layout to you! You can do the same thing with a lot of other info while you are about. I create a page called Site Settings (with a matching template) and I put things like meta keywords, banner, blocks, site title, reusable phone number, anything that I may want to use all over the place. And then just call them into a template. Getting really clever If you want to go completely mad, you can create blocks template ( and associated blocks.php template file) and then create lots of blocks as pages, preferably as children to a hidden page like "blocks" In your Site Settings template or where ever, you can then create a Page field type for each block (choose single and null on the details tab) and set the parent to Blocks and the field to select - a drop down, basically. Now, one your Site Settings page, you can use the dropdown to choose which block you want for each position. Your blocks.php template file will take care of the layout of the block information, you just need to call the pages fields into your footer. For instance: <?php echo $pages->get("/site-settings/")->name_of_pages_field->render(); ?> The render() will then render the entire contents of the blocks page. Does that help? Joss

Minor correction to above: The revision 99 holds the record with 3.870 downloads (published on thursday)!

Ok with "$page_temp->editable()" works fine. $is_preview = $this->input->get->view && $page_temp->editable(); Thanks Soma!

I think we will keep it to just one set of syntax - I get confused enough as it is! Joss

Little Update So, on the help page there is some basic instructions about categories and templates. I have added a simple right sidebar template that you can use for little side notes. Might be good if you want to give a very short howto to accompany the long, detailed version you had just written. Giving a little thought to redirects - for instance I have created a page called Select Field that redirects to Page Field - might help someone who is knew to the system and is wondering where the select field is! I have listed all pages on the front page - when the list gets too long we can remove this, but it might help people to see what is there which they may want to help with or what is missing that they may want to add. I have been putting categories as a sub categories to Processwire to make listing easier later on. Er... that is about it. Oh, started some waffly thing about pages ... like the jokey one I wrote, but without the jokes! It is just an overview - detailed howto will be separate and flagged up at the top of the article so people can move on in a hurry if they want http://wiki.processwire.com/index.php/Pages_Overview Joss

It sounds like a fantastic idea, Matthew, and I certainly agree that Codeigniter has some of the best documentation I've come across with, so it could act as an example to aspire to. In my opinion, and as Soma mentioned in another thread, the main problem novice users face when looking for information is that, more often than not, they don't really know what to look for, so the odds of them finding the right info are pretty slim. I really believe that having 'how-to" articles that address a wide array of different case scenarios would help diminish this problem, and make the current documentation more beginner friendly. The small project walkthrough tutorial that Ryan posted some time ago is a superb example of how this can be implemented. This tutorial helps ProcessWire newcomers understand how the most basic actions are executed in the system, and provides information that will be of use in projects that go far beyond the scope of the case study Ryan proposes. I can say this tutorial helped me understand the system. In my opinion, ProcessWire's documentation is already quite good, but I think, looking at the future, we should go the extra mile to make things easier for those users with less experience with PHP. As it turns out, the number of designers using ProcessWire seems to be growing, and this can only be regarded as a good thing. Adding a collection of project walkthroughs, or how-to articles to the documentation, be that through processwire.com or through any other website, is going to make ProcessWire much more attractive to a much wider audience. This is just my opinion, anyway. Claudio

I somehow wanted to write about the documentation part but left it out in hope it will come up naturally. Thanks for bringing this up again Joss! Exactly sums up what I think about the subject. A software raises and falls with its documentation and support (and some other factors as well). There's a good bit documentation Ryan put together. For people like me it's enough to get started quickly and hardly have to ask questions. This seems not true to most of the audience that ProcessWire seems to attract now which are more design orientated never had to code PHP until now. I'm almost surprised that it really is a good main audience. Though one could arque there's a lot of advanced technical user that haven't even joined the forum yet, but use to search for answers or figure them out them self. Reflecting back the year and a half on this forum, it showed clearly where people are having problems understand the basic principals, and although there's already some documentation there, they don't seem to find it as they don't know how to look for. I always feel a little bad to see so many good threads and QA are hidden in this forum that are hard to find (though with google it is possible) and most of them should be just collected, prepared and put into a place where it can be sorted and searched and listed in a easy way. There's TONS of snippets and code examples! Some are really great information you can't find elsewhere in documentation. I would have started any day building something and only the fact it would take a lot of time is why I haven't started yet. And I'm surprised nobody has yet started something more serious apart from the wiki (which obviously involves some problems). So and you guys tell me you have something on your own! Damnit, then why wait and not make it a movement people who are willing to help and dedicate some free time to the project. I don't think making it wiki style for writing for everyone is a good idea, but make it with a small group of people who have access. ProcessWire can be used to build something easily! But I see it just takes time and the right people to join to get this rolling. I'm happy to see that there's people like Joss understanding this fact and take initiative without even asking them! Thanks to all who decide to help and join the lonely nut to make him the leader.

Greetings, Joss, you and I obviously not only share a similar CMS history, but also a similar outlook on documentation as well. * I've been putting together my own personal documentation on ProcessWire, mostly to remind myself of steps, but -- as predicted -- it's turning into something that might be useful to others... I don't want to be responsible to veering this thread beyond the original poster's intentions, so I'm going to start a separate discussion on this documentation concept. Thanks, Matthew * I think we also have a similar sense of humor, but I'm afraid to uncovee that Pandora's box too much at the moment!

Thanks to you too Soma, and Diogo and Apeisa and all the other people who make this such a welcoming place for newcomers and help out when we inevitably get stuck. I agree that Ryan sets the tone, he's unfailingly helpful and polite and a bonafide genius at just about any web issue I've ever come across! I do wonder, like a few others, how this place will evolve when it grows, will we still be able to maintain the same "intimate" feeling? (Joss I need your help here with the wording!) I agree with Pete that there will probably need to be moderators for different forums. I love this community! PS: I also think the timing of Soma's post is spot on. It does feel like PW is growing by the day.

Ryan definitely set the positive tone on the forums, whether by answering to every kind of question or by cutting any discussion with a more negative tone (toward other open source projects for instance). This kind of attitude is somehow very contagious I'm very pleased to see new people coming and becoming quickly part of the project, and the last two weeks were great in this matter. A big welcome to every one!

Ditto from me to all of the above. I've visited a fair few forums over the years and I've not seen another software-related forum as friendly as this. It definitely has to do with ryan always reading and helping out on the forums from day one. I agree with Soma that there will come a day when ryan can't read or offer code examples in every post and that's when people start getting more selective and eventually you need Moderators for different forums that are fairly specialist in those areas (I'll moderate the Pub forum ) but we're a way off that yet and it's good to see that the friendliness and helpfulness rubs off on new members and everyone helps each other out where they can. The trick is that no matter how fast or big the forums grow, we need to maintain this sense of community - so far it's working just fine!

I agree with all that everyone has said so far and would also like to thank Ryan for this and also everyone else who continues to contribute. I consider my programming skills mediocre at best and when I first joined the forum and saw the level of expertise here, I was a bit hesitant to ask questions. But I have quickly come to realise that no matter what level you are at you will always get the help you need without ridicule and I feel comfortable asking for help now. I am working on my first full-blown site in PW now and hope to share the finished item with you soon. I have spent many hours on it mainly due to my own learning curve for PW, but I have learned a lot along the way. This is a site for my local community and I am doing it for free. Everyone I have spoken with here has been very positive about it, so I just hope that it gets the use that it's intended for.

Thanks Soma this is really nice of you. Thank you also for all the great work that you are doing here! Now I have to logoff for a few days, so this is a great last post to read before I head out. Hope that you all have a great weekend and week! Also please no more Ektron licenses on my credit card.

I found Janko's FormToWizard code to be one of the simplest ways to implement a multi-page/multi-slide form. Now with the Processwire this just got easier. I tweaked his script a wee bit to work with the API forms described in this thread. PWformToWizard.js bunching your fields into fieldsets just as Ryan described above, each fieldset will become a page/slide. Instead using the <legend> tag that Janko uses, the script now generates a legend based on the label, specifically anything that comes before a colon ':' first add the script: <script type="text/javascript" src="PWformToWizard.js"></script> then use this javascript to initiallize formToWizard: $("#SignupForm").formToWizard(); the default styles are: <style type="text/css"> body { font-family:Lucida Sans, Arial, Helvetica, Sans-Serif; font-size:13px; margin:20px;} #main { width:960px; margin: 0px auto; border:solid 1px #b2b3b5; -moz-border-radius:10px; padding:20px; background-color:#f6f6f6;} #header { text-align:center; border-bottom:solid 1px #b2b3b5; margin: 0 0 20px 0; } fieldset { border:none; width:320px;} legend { font-size:18px; margin:0px; padding:10px 0px; color:#b0232a; font-weight:bold;} label { display:block; margin:15px 0 5px;} input[type=text], input[type=password] { width:300px; padding:5px; border:solid 1px #000;} .prev, .next { background-color:#b0232a; padding:5px 10px; color:#fff; text-decoration:none;} .prev:hover, .next:hover { background-color:#000; text-decoration:none;} .prev { float:left;} .next { float:right;} #steps { list-style:none; width:100%; overflow:hidden; margin:0px; padding:0px;} #steps li {font-size:24px; float:left; padding:10px; color:#b0b1b3;} #steps li span {font-size:11px; display:block;} #steps li.current { color:#000;} #makeWizard { background-color:#b0232a; color:#fff; padding:5px 10px; text-decoration:none; font-size:18px;} #makeWizard:hover { background-color:#000;} </style> <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script> <script type="text/javascript" src="formToWizard.js"></script> <script type="text/javascript"> $(document).ready(function(){ $("#SignupForm").formToWizard({ submitButton: 'SaveAccount' }) }); </script> see janko's page for more info~ Now, just to add some responsive jquery validation to each 'next' button...

There will be soon. Just need to figure out how to do it. But that's part of the reasons the $options array is there, so that we can include additional options like crop direction.