Leaderboard

Thanks for the welcome, apeisa! I've some a fair amount of experience with Git, and I'll gladly shed some light. Even if not officially announced (not sure what that means exactly), PW homepage already announces & offers to download PW 2.3.0, and it links to a zipball generated from master, as you mentioned. We could say tht PW 2.3.0 has already shipped. Problem with saying that "2.3.0 is current master" is that master (the branch pointer) may move at any time, when further development (ie. probably a merge commit from dev) happens on it. My suggestion is: tag the commit a8024bb as "2.3.0" and avoid any potential confusion, as may happen now between tags 2.2.9 and 2.2.9-final. I consider that tagging each release is really helpful & useful for others (like, well, me) that have cloned/forked the repo & may need to checkout an old version to work with. Finding a merge commit from dev to master may be a hint that a new version may have been released, but really, it just too ambiguous, imho. But there is something that worries me a bit more... keep reading . 2.3.0 is the merge between branches dev and master. Problem is: there are 11 commits (including the 1 merge commit) that happened directly in branch master, 11 commits that were never merged back to branch dev. Or, in other words, dev branch is currently missing 11 commits. I'd bet that wasn't intended (but correct me if I'm wrong), being that those 11 commits are part of both 2.2.9.final and 2.3.0 releases. Proof of this is the current output (which shows the 11 commits missing from dev branch). $ git log --graph --oneline --decorate dev..master * a8024bb (master) Merge branch 'dev' * d453a76 (tag: 2.2.9.final) Enable the findPagesCode option in Inputfieldpage for non-Fieldtype context use of Inputfield forms (like FormBuilder) * 9b3039d Fix issue with RepeaterPageArray lacking a makeNew() method. * e1c66b3 Update FieldtypePage to support setting by strings like $page->someField = "123|456|789"; * 3a76113 Fix non UTF-8 encode on InputfieldCommentsAdmin cite line * c3334a7 Fix issue with InputfieldCommentsAdmin not working with open/close of individual comments in the page comment editor * 3386764 Fix issue with InputfieldSelect.module that was appearing on select fields with Form Builder forms. * c8e832d Update InputfieldMaxWidth to be 100% rather than 99%. Add isNew reserved word to core/Fields.php. * ac24667 Minor fix to InputfieldCheckbox.module * 9b796be Fix InputfieldCheckbox so that it displays proper label (rather than value) * e937903 (tag: 2.2.9) Fix issue with InputfieldRepeater 'add item' giving a JS error in some cases. To get out of this situation, one solution (probably the most correct one) is to merge branch master back to branch dev. These are the steps: $ git tag -a 2.3.0 master # As suggested previously, add the corresponding release tag # Alternatively, you could do: "git tag -a 2.3.0 a8024bb" # as a8024bb is less ambiguous, as it is the commit corresponding # to the 2.3.0 release (the current tip of master branch) $ git checkout dev # Switch to dev branch $ git merge master # Merge master branch into dev branch # Alternatively, if you tagged the master branch as suggested, you could do: "git merge 2.3.0" That will create a merge commit and then, the 11 missing commits will now be part of the dev branch, putting PW development back on track. Please, don't hesitate in getting back to me or reaching me at #processwire on irc.freenode.net (my nickname there is Mannequin).

Okay, I did some work on this today - adding, updating, renaming, deleting and changing the type of Fields now records and repeats. I have only done some superficial testing of this: created and deleted some fields, changed properties on various tabs, renamed a Field, deleted one, and was able to repeat all of those actions, without problems. Tables were correctly created, renamed and deleted during those operations. I'm impressed with how robust ProcessWire is in this regard - because the important stuff really does happen at the API-level (rather than in controller/action methods) all the operations are easily repeatable and the results appear to be consistent Nice work @ryan ! Now, there is one thing that concerns me. $this->addHookAfter('Fields::load', $this, 'hookFieldLoaded'); $this->addHookAfter('ProcessField::fieldSaved', $this, 'hookFieldSaved'); $this->addHookAfter('ProcessField::fieldAdded', $this, 'hookFieldAdded'); $this->addHookAfter('ProcessField::fieldDeleted', $this, 'hookFieldDeleted'); $this->addHookAfter('ProcessField::fieldChangedType', $this, 'hookFieldChangedType'); I'm hooking into Fields::load to obtain a copy of all the Field properties before any changes can be made to these. But in order to capture the changes, I had to hook into the ProcessField::field* methods, which appear to be there for the purpose of monitoring these events. My concern is that those events only fire when changes are made via the ProcessField controller - and that this is not (necessarily) the only way to make changes to Fields. (I no longer recall why I had to use the controller-level events, as opposed to hooking into the Fields collection-level events - I will investigate this further the next time I work on this.) I would really like to hear from @ryan on this one before I continue - there are currently no equivalent controller-level events for Templates (e.g. in ProcessTemplate) as far as I can tell? So currently the only option is to hook directly into the Templates collection methods.

Hey guys, another green website from the processwire beginners based near munich. This website is our first REAL PW project - and (for us) one of the biggest sites we‘ve ever built. And actually the first one with a CMS/framework that we did totally on our own. So, don‘t be too negative - but don‘t be too positive either. http://www.roha-gmbh.de There are still many things that are not perfect yet, but since we started to design this website in 2011, it really was time to get it "into the wild" now! Many furniture manufacturers still haven‘t sent their best product images, so that is why there are still some lowres images in there. The project chapter needs some work on the photos as well, but that time will come... The site is not responsive yet, because it wasn‘t our main goal in 2011 - so we only wanted to get it working on tablets and phones, but without any special mobile styles. This will come, but that may take a while. The modules we used: - formbuilder - procache - redirects - versioncontrol - sitemapxml I‘m totally glad I found processwire a few months ago, because at first we planned to get that site done with pure static html. Which would not be TOO nice with about 80 html pages and many, many images (about 400). Finally a few "thank you"s to ryan, soma, diogo (for creating processwire and your help in this lovely forum) and to mademyday (for posting this on twitter, which made me read about processwire). Comments are welcome! Of course!

Hi, I had some free time so i made this patch to improve PW localization support little more. Changes are made in these files: /wire/modules/Fieldtype/FieldtypeCache.module /wire/modules/Fieldtype/FieldtypeComments/FieldtypeComments.module /wire/modules/Fieldtype/FieldtypeComments/InputfieldCommentsAdmin.module /wire/modules/Fieldtype/FieldtypeComments/CommentFilterAkismet.module Seems like localization dont work for file CommentForm.php I can overload strings in frontend template file but not thrue standard localization file. Example: /srv/http/pw_translate/wire/modules/Fieldtype/FieldtypeComments/CommentForm.php: 122 123 // default labels 124: $this->options['labels']['cite'] = $this->_('Your Name'); 125 $this->options['labels']['email'] = $this->_('Your E-Mail'); 126 $this->options['labels']['website'] = $this->_('Your Website URL'); Ryan: can you check this patch and merge it please?

This sounds awesome mindplay.dk! That's a valid concern, since modules or other API usages that are adding/manipulating templates/fields would not be triggered from the Process ones. Though if you only wanted to capture changes made interactively, that would be the place to do it. Attached are replacements for /wire/core/SaveableItems.php and /wire/core/Fields.php. They contain additional hooks, which I think may be more what you are looking for. Let me know if these work out, and I'll commit them to the core. I'm a little short on time this afternoon, so haven't had a chance to try them myself, though the additions are very minor and simple so can't think of any reason why they wouldn't work. mindplay.zip I added a few hooks to SaveableItems.php which is used by both Fields and Templates. You can hook these either by wire('fields')->addHook('methodToHook', $this, 'yourMethod') or $this->addHook('Fields::methodToHook', $this, 'yourMethod'). To operate on templates, you would replace 'fields' with 'templates'. Here are the hooks, and they work exactly like their Pages class counterparts: public function ___saveReady(Saveable $item); public function ___deleteReady(Saveable $item); public function ___saved(Saveable $item); public function ___added(Saveable $item); public function ___deleted(Saveable $item); These two were also added to the Fields class (in the attached zip): public function ___changedType(Saveable $item, Fieldtype $fromType, Fieldtype $toType); public function ___changeTypeReady(Saveable $item, Fieldtype $fromType, Fieldtype $toType); For all of those above, it doesn't matter if you hook before or after. For the existing hooks that were already there, it does matter whether you hook before or after. Though not sure if you necessarily need any of these: protected function ___changeFieldtype(Field $field); // Fields class only public function ___saveFieldgroupContext(Field $field, Fieldgroup $fieldgroup); // Fields class only public function ___clone(Saveable $item); public function ___delete(Saveable $item); public function ___save(Saveable $item); protected function ___load(WireArray $items, $selectors = null); Let me know if there is anything else I can add/adjust to facilitiate what you are working on.

We've just launched a new company, early days and we needed to get a site out quickly. http://www.milktop.co.uk Still plenty of fiddling to be done and we're pretty busy on other work, just didn't want to be one of those web companies without their own site

Hey, I'm planning to do a Interrail trip through Europe in July. The trip will (hopefully) look like this: Berlin -> Amsterdam -> Paris -> Bordeaux -> (Madrid) -> Lissabon/Porto -> Wien/Vienne -> Berlin Now I have to look for some places to stay and I thought maybe here are some people who live in the cities mentioned above or next to them and maybe have a idea where to stay for 2-3 nights per city... (Like for example I saw that diogo is living in Porto so it would be lovely to maybe meet you and say hi or stuff like this ) Would be really, really lovely if someone here could support me here! Much love to processwire community <3 Nico Btw.: The website isn't ready but running with PW of course: http://interrail.nico.is

Hi guys, Finished this one up in Jan, been meaning to post it. Have a few more that are done but need some final polish, I'll post those up soon. www.contactla.com - Pretty simple site, but client was extremely happy with the setup and how easy it is for them to change content/pricing tables. Can't really express how much I enjoy doing sites in processwire. THANK YOU RYAN !!!!!!

Ryan, thanks for the prompt reply. It seems both of us are right. From a ProcessWire codebase point-of-view, you are right: almost all the code written (added/removed) on those 11 missing commits is already on dev. I say almost because there are 3 lines of code introduced in master that are still missing in dev, as you can see below. $ git diff dev...master diff --git a/wire/modules/Fieldtype/FieldtypePage.module b/wire/modules/Fieldtype/FieldtypePage.module index 06e0f65..c5e2669 100644 --- a/wire/modules/Fieldtype/FieldtypePage.module +++ b/wire/modules/Fieldtype/FieldtypePage.module @@ -254,6 +254,9 @@ class FieldtypePage extends FieldtypeMulti { } else if(ctype_digit("$value")) { // page ID $result = $this->pages->get("id=" . $value); + + } else if(strpos($value, '|') !== false && ctype_digit(str_replace('|', '', $value))) { + $result = $this->pages->getById(explode('|', $value)); } else if(strpos($value, '|') !== false && ctype_digit(str_replace('|', '', $value))) { // CSV string separated by '|' characters So, again, you are correct: at some point, probably by copy-pasting chunks of code, you introduced into dev the pieces of code (the changes) on those 11 commits. A proof of that is that the changes introduced in commit 9b3039d (an atomic change, only present in master) are also part of commit 7dab612, which is a huge commit in dev. It's almost as if you cherry-picked (see git cherry-pick) but in a manual, human, untidy way. So far, so good. And the only changes you missed to move manually are those shown on the git diff output above. From a Git point-of-view, I'm right: 11 commits done in master aren't part of the dev branch. Even Github shows that same info here (dev is 11 commits behind and 4 ahead of master) and here (comparing both branches, it shows the same diff as above). Technically speaking, from a Git point-of-view, master and dev have diverged. So, now that we all have a better understanding of what happened and what is missing from dev branch (just 3 lines of code), let me suggest what would have been better options to bring the changes from those 11 commits in master branch back to dev branch. As said, Ryan, you did it manually, but that's prone to (human) errors, as changes could be missed and/or introduced with errors. First (best) option: as suggested on previous post, just merging master (righ now, or back at the time when you did those 9 commits now known as "2.2.9.final") back to dev is all that's needed. Right now, that action will just bring to dev those 3 lines of code missing, by creating a merge commit. In the graph, it will clearly show that those commits are part of dev and there won't be any doubt. Back at that time, that action would have bring the many lines of code missing, releasing you from the task (human & prone to errors) of manually having to copy-paste them. Second option: git cherry-pick. Right now, this option won't make sense, as you already "cherry-picked" the changes from master back to dev in a human fashion. Back at that time, if for some reason (I can't think of one) you couldn't merge master back to dev, git cherry-pick would have been the best option, as it lets you manually pick which commits from master you would like to re-apply to dev. Take into consideration that cherry-picking commits from a branch (ie. master) creates new commit objects on the destination branch (ie. dev). A commit created by a cherry-pick will have a different hash than the original commit (the one cherry-picked), but it will introduce the same exact set of changes (ie. the same +/- patches). Bottom line: while standing on dev branch run "git merge master" and call it a day. Mmmmm. Personally, I'll suggest to stay with the "dev" name for the development branch. Something you could do is that, after some release (ie. 2.3.0), on the next commit, on some project file (ie. readme.txt, or changes.txt, or version or whatever you use) you rename the version to 2.3.1-dev. In this example, it's important to get that "2.3.1-dev" means "the development done for next 2.3.1 version", and not "the development done after 2.3.1 release". Then, on some place of the PW admin, you could print "ProcessWire (2.3.1-dev)". But the question remains: at which exact commit of the many commits that may correspond to the development of 2.3.1 is this PW installation standing at? I'm not sure what's the answer for this, but Git may be helpful here. There is the git describe with "shows the most recent tag that is reachable from a commit". For example, if in your PW repo you run: $ git describe master You will get this output: 2.2.9.final-174-ga8024bb Which means that master branch is 174 commits above the "2.2.9.final" tag, more precisely in the commit a8024bb. The "g" is just a prefix to indicate that is a commit done in Git. So, as you can see, there is a good way to describe where is standing someone in relation to last tagged version. Ryan, 2 last things: First, as you are the BDFL and main commiter of ProcessWire, I'd suggest you to begin using annotated tags: http://git-scm.com/book/en/Git-Basics-Tagging#Annotated-Tags Second, I'd suggest taking a peek at this Git branching model: http://nvie.com/posts/a-successful-git-branching-model/ It's a pretty popular one, and it may fit into the way PW is currently being developed. Even if you don't want to follow that (or any other) particular branching model, the article is pretty good to clear up some concepts. That's all by now, thanks for reading.

I just posted an update to the LanguageSupportPageNames module that appears in the 2.3 dev branch. The screenshot explains it best: Basically, you can uncheck the "active" box for any language, and that page becomes unpublished, for that language only. It behaves the same way as an unpublished page, in that it doesn't show up in searches, and produces a 404 if you try to view it (unless it's editable, in which case you can still see it). You don't see a checkbox next to the default language, because that one is controlled the same way as before (via the page's unpublished status).

Hello All, I work for a brand communications agency in London as head of digital. We work exclusively with Drupal. We are now looking to experiment and build a few sites with PW. Im looking to expand my knowledge and my contact list. If you are in or around London and can potentially commit to 37.5 hrs a week for a few months please drop me a line. Remote work is also possible for the right candidate. You will be required to take a sitemap, .ai visuals and bring it all alive. Keywords HTML, CSS, jQuery and PHP. Ideally you need to have built at least 5 PW sites with different features and capabilities. If this sounds like you please say hi. Kind regards, Hasan Akyol hasan dot akyol at andesign dot co dot uk

@RJay Here the step to get it working. You need to enable two plugins and add the "rel" attribute to the valid elements in TinyMCE. You can edit the configuration of TinyMCE on the field settings under the tab "Input". There's a collapsed fieldset TinyMCE Advanced Configuration Options. Add the two plugin contextmenu and advlink to the plugins text field: ...,contextmenu,advlink Then in the field valid_elements add rel to the @[id|class] so it won't get stripped off: @[id|class|rel] Now when you have done that you go edit your text and add a link using the PW link dialog. Then click on the link using context menu (right click) and select "Insert/Edit link". You'l be presented with a ton of attributes you can set to the link. But you need to also add them to the valid_elements first.

Here use this: <?php $sent = false; $error = ''; $emailTo = 'YOUR EMAIL ADDRESS'; // or pull from PW page field // sanitize form values or create empty $form = array( 'fullname' => $sanitizer->text($input->post->fullname), 'email' => $sanitizer->email($input->post->email), 'comments' => $sanitizer->textarea($input->post->comments), ); // check if the form was submitted if($input->post->submit) { // determine if any fields were ommitted or didn't validate foreach($form as $key => $value) { if(empty($value)) $error = "<p class='error'>Please check that you have completed all fields.</p>"; } // if no errors, email the form results if(!$error) { $msg = "Full name: $form[fullname]\n" . "Email: $form[email]\n" . "Comments: $form[comments]"; mail($emailTo, "Website contact form submission", "$form[comments]", "From: $form[email]"); // populate body with success message, or pull it from another PW field $page->body = "<div id='message-success'><p>Thanks, your message has been sent.</p></div>"; $sent = true; } } if(!$sent) { // sanitize values for placement in markup foreach($form as $key => $value) { $form[$key] = htmlentities($value, ENT_QUOTES, "UTF-8"); } // append form to body copy $page->body .= <<< _OUT $error <form action="./" method="post" id="contact-form"> <fieldset> <legend>Send a note</legend> <ol> <li class="form-row"> <span class="error" style="display: none;" ></span> </li> <li class="form-row"> <input id="fullname" name="fullname" type="text" size="30" class="name required default" title="Your name" value="$form[fullname]"/> </li> <li class="form-row"> <input id="inputemail" name="email" type="text" size="30" class="required email default" title="Your email address" value="$form[email]" /> </li> <li class="form-row"> <textarea name='comments' rows='5' cols='45' id='comments' title="Your message">$form[comments]</textarea> </li> <li class="form-row"> <input type="submit" name="submit" value="Send" class="submit-button"/> </li> </ol> </fieldset> </form> _OUT; } ?><?php /** * Contact form template * */ include("./header.inc"); ?> <div class="main-container"> <div class="main wrapper clearfix"> <article> <section> <?php echo $page->body; ?> </section> </article> </div> <!-- #main --> </div> <!-- #main-container --> <? include("./footer.inc"); Oops and here is the jquery for validation: $(document).ready(function() { $(".default").each(function(){ var defaultVal = $(this).attr('title'); $(this).focus(function(){ if ($(this).val() == defaultVal){ $(this).removeClass('active').val(''); } }); $(this).blur(function() { if ($(this).val() == ''){ $(this).addClass('active').val(defaultVal); } }) .blur().addClass('active'); }); $('.submit-button').click(function(e){ var $formId = $(this).parents('form'); var formAction = $formId.attr('action'); defaulttextRemove(); var emailReg = /^([\w-\.]+@([\w-]+\.)+[\w-]{2,4})?$/; $('li',$formId).removeClass('contact-form-error'); $('span.contact-form-error').remove(); $('.required',$formId).each(function(){ var inputVal = $(this).val(); var $parentTag = $(this).parent(); if(inputVal == ''){ $parentTag.addClass('contact-form-error').append('<span class="contact-form-error">Required field</span>'); } if($(this).hasClass('email') == true){ if(!emailReg.test(inputVal)){ $parentTag.addClass('contact-form-error').append('<span class="contact-form-error">Enter a valid email address.</span>'); } } }); if ($('span.contact-form-error').length == "0") { $formId.append($loading.clone()); $('fieldset',$formId).hide(); $.post(formAction, $formId.serialize(),function(data){ $('.loading').remove(); $formId.append(data).fadeIn(); }); } e.preventDefault(); }); function defaulttextRemove(){ $('.default').each(function(){ var defaultVal = $(this).attr('title'); if ($(this).val() == defaultVal){ $(this).val(''); } }); } });

It's in the dev branch now

SOLVED Hello people! This is my first post at the processwire forum. There is something i can't figure out. The best way to explain my problem is to go to the following website: followmylegends.com. When you try to register a small pop-up is coming. Now my question is how can I fill the pop-up with content with jquery? ($.get, or AJAX) When i try something like this it wont work. $('#register, #forgot').click(function(e){ var div = $(this); e.preventDefault(); $.get($(this).attr('href'), function(data) { $('#'+$(div).attr('data-reveal-id')).html(data); }); }); Then I get an error: GET http://www.followmylegends.com/site/templates/register/register.php 404 (Page Not Found) But the file is in templates/register/register.php. Can somebody help me? Thx, John Update Sorry for this topic.. This was a bit timewasting like 3 hours. I have to learn more about processwire. What I did was create a new template. Use it for a page and called it with url.com/register/ Sorry again..

Hello there Peter, This may not be of much help, but still wanted to point out that exporting data from ProcessWire for specific needs, ie. where you can easily define what data / which parts of your site / which templates you wish to export is relatively easy to achieve, just not with direct SQL queries: Bootstrapping PW and writing simple command-line script that exports data is one method I've used in the past. Another method, which is especially helpful if you only need to export specific templates, is creating a template file that instead of HTML serves JSON, XML, CSV or whatever format you prefer, accompanied with proper headers of course. If you need to export multiple pages, it should again be easy to write a template file that finds pages you need and renders each of them one after another with render() method of Page object. This is actually something I've just recently used for Excel export on a relatively large client site, accompanied with various user-defined search criteria. Works like a charm. You could also combine these two by writing a command-line script that does exactly what I've described above for exporting multiple pages simultaneously. As a neat little trick you could also switch template file used for rendering by altering the value of $page->template->filename on the fly per page in order to have "export template file" while still avoiding any unnecessary changes or complex logic at the site itself. This is still pretty far from generic export method, but has so far fulfilled all my export needs perfectly fine. PW doesn't force any limits on what you can do with your template files, which is one of the reasons I find it such a wonderful platform for pretty much anything web-related.. and even some non-web-related things

They were just setup as child pages for each table and then children for each table row with a basic template containing a name field and 4 text fields for each cell. I think I just built the table markup from a basic foreach in the main template file, nothing really fancy.

This is easy one to like really. We old foxes all remember you as "the one who asked about every possible (and impossible) question there is". Sometimes it almost felt you were there to annoy us It didn't took long though and soon you started answering other member's questions with great answers. And now we also see very unique and high quality PW-site coming from you! All this in under a year.. just wow and congratulations! It's great to have you here.

I moved few posts from here to another topic: http://processwire.com/talk/topic/3186-roderigo-maryla/ Also removed the ones that were discussing about moving to another topic to keep this focused. We do love good fun, but since clients also looks for these topics (through Google etc) it is nice to keep these showcases on topic.

http://processwire.com/talk/topic/2387-the-structure-of-fields-and-templates/?p=22762

Just installed it on our new site http://www.milktop.co.uk and seems very snappy. Don't know if it's the same for everyone? I probably haven't tweaked it very well and the site itself hasn't been completely optimised but so far seems like a good purchase!

Thanks Diogo! Seems to work very well. I've added to the source and will test locally for a day or two, then push it to the dev branch.

Detroy the world if you wish, just let us know when you got a version running.

The Beach Boys before and after Processwire Before: After: https://www.youtube.com/watch?v=9kg-pYItaj8

Once the multi-language page names module is stable and in production use. So will probably start developing the namespaces stuff in May. Namespaces are the primary aim, with PSR-0 being a natural extension of that. I plan to shoot for PSR-1 too if it looks like it'll benefit our audience. Also as a natural extension to these updates, I am interested in supporting Composer, and will do so if possible. I agree it's a great asset for PHP, though am less certain if it's as much of a draw for ProcessWire's primary audience. Throughout all of these 2.4 updates, I feel a lot of care will have to be taken to balance these updates with other improvements to the system. After all, our audience is primarily web designers and developers, and less purely PHP coders. I think a majority of our users doesn't actually care about namespaces, PSR standards and Composer, so I don't want to get too far off track, even if I personally have a strong desire for these things. But the driving aim of 2.4 is to help ProcessWire benefit from PHP 5.3+ as much as possible. This likely includes all of the things outlined. I've always been interested in this. PW started as just the content framework, and underneath it still is. I'd like to retain and reinforce those roots. But don't think I want to actively maintain PW as two projects until there is real need for it (just as a matter of resources). I'd like to make it easy for people to integrate components if they want to, and I think Composer is probably the way to do that. But don't currently see a need for any of our core components to come from another framework. Though I'm always open to the idea if there is a real benefit to our users. IoC is not a new concept. ProcessWire was written with an emphasis on best practices, patterns and concepts like this, everywhere beneficial to the project goals. The primary need for unit tests in PW has been with the selector engine, both DB and in-memory, and the consistency of the two. Luckily this is an active project, and it has already been hugely helpful and influential in ProcessWire 2.3 (thanks to Nik). In fact, I would probably consider the issues discovered and resulting solutions the most important upgrade to come with ProcessWire 2.3.

I haven't given up on this, and I came quite far. It's been a couple of months since I worked on it - last couple of months have been kind of hectic for me, so I haven't made any recent progress. I do want to work on this, and still believe it's possible - since I gave up on using $trackChanges, the approach I'm using should be pretty safe. Probably a couple of weeks of work left on this at least though, and not sure when I'll get back to it...

Generally I don't add tags except when we need to link to something from the past. Since 2.3.0 is the current master, I didn't think it needed a tag yet. Though I was going to add it anyway once 2.3 is officially announced. 2.2.9.final was just to mark the spot where it was at before merging in the dev branch. I would have called it 2.2.10, except that I wanted 2.2.9 to be the last version number in the 2.2 version (since we'd used 2.2.10+ for dev branch). The 2.2.9 version that people have been installing is 2.2.9.final. For the most part you can ignore tags with ProcessWire, as we don't use them for anything other than making links to past things, when necessary. The passwords and hashes won't change until the user actually changes their password. Basically it leaves it alone until the password changes. If you have an existing site and you want to take advantage of the better security of blowfish hashes, you should ask users to change their password. For admin users, it gives you a notice that you should change your password when possible.

maniqui: welcome to the forums and thanks for your feedback. I think Ryan has been experimenting with tags, but not yet fully in use. We are just learning Git If you are experienced with git / github, it would be very valuable if you (and others of course) can shed a light how the ideal workflow with releases / tags should go.

In the latest commit to the ProcessWire dev branch, the LanguageSupportPageNames module now supports setting the homepage name for any of the languages. It should work exactly like how you guys requested. For example, if you set the Spanish homepage name to be "es", then from that point forward, all URLs for Spanish are preceded by an "/es/". Likewise, if you access any path preceded by an "/es/" then the user's language is set to Spanish. If you access the homepage "/" then the default language is set. If you access the Spanish homepage at "/es/" then you get the Spanish version of the homepage. Lets say that you set your "default" language homepage name to be "en". In this case, all default language pages become preceded with "/en/", except for the homepage itself… I wanted to avoid having two URLs that render the same exact thing. Use of this homepage "name" is completely optional. You could choose to not use it for your default language, and then use it for other languages, or you could choose to not use it for any, or you could choose to use it for all. Basically, I think it'll accommodate just about anything you could want to do in that respect. Let me know if you guys get a chance to test it and if you run into any snags or other ideas.

Great tutorial Soma! This is the best summary of using PW's Inputfields that I've seen. I noticed you did $field->attr('id+name', 'email') so just wanted to explain what that is for those that may be unsure of the syntax. That syntax is basically saying to set the 'id' and 'name' attribute to have the 'email'. While every field needs a 'name' attribute (like in HTML) the 'id' attribute is optional… if you don't assign an id attribute, PW will make one up. If you intend to custom style a field with CSS or target it from javascript, then it's best to assign your own 'id' attribute. Otherwise, it doesn't matter. // this… $field->attr('id+name', 'email'); // …is the same as: $field->attr('id', 'email'); $field->attr('name', 'email'); // …as is this (direct reference): $field->id = 'email'; $field->name = 'email'; The advantage of using the attr() function over direct reference is that attr() can't ever collide with other Inputfield properties that might have the same name as a field attribute. It's basically your way of saying "this should definitely be an HTML attribute and not anything else." For recognized attributes like 'name' or 'value' it doesn't matter what syntax you use because an Inputfield already knows 'name' and 'value' are standard HTML attributes. But if you needed to add a custom attribute like "data-something", well then you'd definitely want to use the attr() method of setting. That attr() method should only be used for things that would actually be HTML attributes of the <input>, because they will literally end up there. So if you do an $field->attr('label', 'Hello'); you'll end up with an <input label='Hello'> in the markup, which is obviously not something that you want. That's why you assign a non-attribute property like 'label' or 'description' directly, like: $field->label = 'Something'; Last note about $attr() is that it can be used for both setting and getting attributes: $field->attr('value', 'something'); echo "The field's value is: " . $field->attr('value'); // same as: $field->value = 'something'; echo "The field's value is $field->value"; To extend your example, lets say that you wanted the 'email' and 'password' fields in a fieldset titled "About You". You would create the fieldset, and then add/append the fields to the $fieldset rather than the $form. Then you'd add the $fieldset to the $form: $fieldset = $modules->get('InputfieldFieldset'); $fieldset->label = 'About You'; $field = $modules->get("InputfieldEmail"); $field->label = "E-Mail"; $field->attr('id+name','email'); $field->required = 1; $fieldset->append($field); // append the field $field = $modules->get("InputfieldPassword"); $field->label = "Password"; $field->attr("id+name","pass"); $field->required = 1; $fieldset->append($field); $form->append($fieldset); Or lets say that you wanted those 'email' and 'password' fields to be each in their own column so that are next to each other horizontally rather than vertically. You would assign the 'columnWidth' property to both the email and password fields. In this case, we'd give them both a value of 50 to say that we want them to be a 50% width column: $field->columnWidth = 50; To jump out of tutorial mode and into idea mode: lately I've been thinking that PW should have a YAML to Inputfields conversion tool in the core (something that would be pretty easy to build), so that one could define a form like this: And create it like this (where $yaml is the string above above): $form = $modules->get('InputfieldForm'); $form->load($yaml); echo $form->render();

I'm having the same problem with a new website. I moved PW from my testing server to a subdirectory of the new server because i don't want to replace the old site for now. It shows the homepage, but when I press the links, I get a 404 from the server. I asked the server if mod-rewrite is on, and they told me to add "RewriteEngine On" to my htaccess file... not helpful at all... I added some random characters inside "<IfModule mod_rewrite.c>" on PWs htaccess, and it does throw a 500 error. Another thing I just did: I moved PW files to the root and put the old site files on a folder (thre wasn't any htaccess file on the root). PW shows me the homepage, but when I go to subpages, instead of a 404 I get a 500 (??)... back to the subfolder, I get the 404 again. EDIT: I solved this issue by uncommenting this line on the .htaccess: # RewriteBase / (on the subfolder I added RewriteBase /subfoldername/)