ryan

I think either is a good idea. But maintaining the files ready-to-translate is good just so that people don't have to click to add each of them manually. So I will plan to prepare that. Currently I locate the files with a grep command in the shell to find them all: cd wire grep -Rl '[>_][_nx](' * | uniq It's not a 100% as it may include 1 or 2 things it doesn't need to, but should catch everything translatable. core/Fieldtype.php core/Inputfield.php core/InputfieldWrapper.php core/LanguageFunctions.php core/SessionCSRF.php core/Wire.php modules/Fieldtype/FieldtypeComments/CommentForm.php modules/Fieldtype/FieldtypeComments/CommentList.php modules/Fieldtype/FieldtypeDatetime.module modules/Fieldtype/FieldtypeFloat.module modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module modules/Fieldtype/FieldtypeRepeater/InputfieldRepeater.module modules/Inputfield/InputfieldAsmSelect/InputfieldAsmSelect.module modules/Inputfield/InputfieldButton.module modules/Inputfield/InputfieldCheckbox.module modules/Inputfield/InputfieldCheckboxes/InputfieldCheckboxes.module modules/Inputfield/InputfieldDatetime/InputfieldDatetime.module modules/Inputfield/InputfieldEmail.module modules/Inputfield/InputfieldFieldset.module modules/Inputfield/InputfieldFile/InputfieldFile.module modules/Inputfield/InputfieldFloat.module modules/Inputfield/InputfieldForm.module modules/Inputfield/InputfieldHidden.module modules/Inputfield/InputfieldImage/InputfieldImage.module modules/Inputfield/InputfieldInteger.module modules/Inputfield/InputfieldMarkup.module modules/Inputfield/InputfieldName.module modules/Inputfield/InputfieldPage/InputfieldPage.module modules/Inputfield/InputfieldPageAutocomplete/InputfieldPageAutocomplete.module modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelect.module modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelectMultiple.module modules/Inputfield/InputfieldPageName/InputfieldPageName.module modules/Inputfield/InputfieldPageTitle/InputfieldPageTitle.module modules/Inputfield/InputfieldPassword.module modules/Inputfield/InputfieldRadios.module modules/Inputfield/InputfieldSelect.module modules/Inputfield/InputfieldSelectMultiple.module modules/Inputfield/InputfieldSubmit/InputfieldSubmit.module modules/Inputfield/InputfieldText.module modules/Inputfield/InputfieldTextarea.module modules/Inputfield/InputfieldTinyMCE/InputfieldTinyMCE.module modules/Inputfield/InputfieldURL.module modules/Jquery/JqueryWireTabs/JqueryWireTabs.module modules/LanguageSupport/LanguageParser.php modules/LanguageSupport/LanguageSupport.module modules/LanguageSupport/ProcessLanguage.module modules/LanguageSupport/ProcessLanguageTranslator.module modules/Markup/MarkupPageFields.module modules/PageRender.module modules/Process/ProcessField/ProcessField.module modules/Process/ProcessForgotPassword.module modules/Process/ProcessHome.module modules/Process/ProcessList.module modules/Process/ProcessLogin/ProcessLogin.module modules/Process/ProcessModule/ProcessModule.module modules/Process/ProcessPageAdd/ProcessPageAdd.module modules/Process/ProcessPageClone.module modules/Process/ProcessPageEdit/ProcessPageEdit.module modules/Process/ProcessPageEditImageSelect/ProcessPageEditImageSelect.module modules/Process/ProcessPageEditLink/ProcessPageEditLink.module modules/Process/ProcessPageList/ProcessPageList.module modules/Process/ProcessPageSearch/ProcessPageSearch.module modules/Process/ProcessPageSort.module modules/Process/ProcessPageTrash.module modules/Process/ProcessPageType/ProcessPageType.module modules/Process/ProcessPageView.module modules/Process/ProcessPermission/ProcessPermission.module modules/Process/ProcessProfile/ProcessProfile.module modules/Process/ProcessRole/ProcessRole.module modules/Process/ProcessTemplate/ProcessTemplate.module modules/Process/ProcessUser/ProcessUser.module modules/System/SystemUpdater/SystemUpdater.module modules/Textformatter/TextformatterEntities.module templates-admin/default.php templates-admin/topnav.inc

You could also create and add a checkbox field to your template(s) and call it something like "sticky". When a page has the box checked, it will stick to the top of the list. Then when you perform the call to load your pages, sort by -sticky first, then by -date, i.e. $pages->find("parent=/news/, sort=-sticky, sort=-date");

Glad you figured out the start=0 thing for the news_index. When you are using pagination, PW will attempt to paginate all of your find() or children() function calls that have any limit=something. So adding start=0 is the way to keep them in check. For the categories template, the only "limit=" statement that I see says "limit=1". In order for pagination to be activated, there has to be a limit greater than 1. You may be able to get the result you want by doing a $pages->find("limit=2, start=" . ($input->pageNum-1)); and then just using the first page it returns.

The source files themselves are in English, so the only time translation files are needed is if you want to change them (whether changing the language, or changing the English). I could maintain an English translation pack (with unpopulated fields), though it would be something that would only be useful as a starting point for other language packs. Still, if that would be helpful to other people, I'll be glad to do it.

I'd definitely be interested if I wasn't so far away. I think it'll be a little while before there is any kind of PW meetup in the US because the general web dev population here is just now discovering what you can do with WordPress, Drupal and EE, about 5-10 years after the rest of the world did. I think I'm the only one in my state (GA) developing in it. For some reason, any time I bring up ProcessWire around another developer here, it always leads to us looking at their "cool Wordpress sites".

Are you outputting anything before the login() or redirect() functions? The login() function sets a cookie and the redirect() function sends a header, so those things need to happen before any output as started. Meaning, this stuff would need to go at the very top of your page, before any <html>.

I'm confused -- the site link you sent to me seems fully functional. I can't find any error messages?

I don't know what the capabilities or limitations of the software are, but I'm all in favor of anything multi language.

If it's alright with you, we might want to keep the topic here in case anyone else comes up with a similar issue in the future. I had thought that mysqli had some performance benefits over the older PHP mysql, but not positive on that. I think mysqli has been standard since PHP 5.0, though I recently came across a PHP 5.2.x server that did not have it (luckily all it took was a few clicks in WHM to install). The PHP developers started encouraging us to use mysqli rather than the old mysql functions when PHP 5 came out. As far as I know, the old mysql functions are no longer actively developed for PHP, just maintained for backwards compatibility.

With the new datepicker, the only time you should see the YYYY-MM-DD input is if that what you have selected as your input format. If you have selected some other input format, then the datepicker should use only the format you selected. This is one of the main differences between the new datepicker and the old one. The behavior you are describing sounds to me like you may still have the old datepicker. The new one has been stable for me all week, so I will go ahead and commit the new one to the source this weekend or early next week.

It's not the encode I'm worried about (where speed doesn't matter too much). It would be stored as a JSON string, just like PW field/template/module settings. These are unique groupings of data that don't gain any value from being normalized, sortable or searchable. It just needs to be quickly accessible and decoded as a group. Similar to how WordPress and Drupal uses serialize() / unserialize() for this stuff. So the decode needs to be fast, but the encode doesn't. I suppose we could always store it literally as a PHP array, but then would have to eval(), which I try to avoid. Could also store as a PHP array directly in a file that could be include()'d and no decoding necessary.. but then I'd have to figure out how to encode an array to a PHP array string, and not really sure how to do that.

I've not been good at updating module version numbers. But this seems like it'll be a good reason for me to start doing it.

It's got to be browser cache like Antti said. Hit reload a couple of times in your browser while on a page with the datepicker. Also, you'll be glad to know I've got an update just about ready that should prevent this particular browser cache issue that comes up regularly. Basically, the admin template will append the module version numbers to the CSS and JS files, i.e. "module.js?v=102", hopefully communicating to the browser that something has changed.

They will stay separate logins. So congrats on being user id #2 Right now the Wiki is wide-open, so you can make edits without having an account too.

The problem is that line above. You are calling $session->logout(); rather than providing a URL to logout. Since you are calling the logout() function, it is logging them out. What you want to do instead is link to some other page that logs them out. Something like this: <li><a href="./?logout=1">Logout</a></li> Then in your template file, or header include, or anywhere before you output anything, you'd want to check for that URL: if($input->get->logout) $session->logout();

Seems like a great idea -- I just now added it in the latest commit. Now it should support the "sort=template".

There actually is a way around that, but it was a lot more complex than you'd think. Had to setup a translation table between PHP date(), PHP strftime(), Javascript/jQuery and regular expressions. But the result is that your date format will be retained without limitation. Grab the file from here, and you should have a lot more options for the datetime fields too: I'll be committing this to the core soon.

This is purely for controlling the presentation in the admin side. It really doesn't mean much on the front-end of your site, unless you iterate the $page object (in which case the fields will follow the same order).

Raoul, I don't think you can easily change the storage mechanism for sessions at this time. However, you'll be glad to know that the option of database session storage is a priority for the next version and the code is already underway here. Until that time, I'm not sure how you could run ProcessWire admin. But are you certain the server doesn't allow file-based sessions? PHP uses files for sessions natively, and by default, so it would be unusual in any hosting environment for that not to be an option. If you want to tell me more about the hosting environment, perhaps we can find a way around whatever limitation is in place there.

Neon looks pretty cool! But will probably stick with JSON here, just because PHP has the built-in json_encode/json_decode, which are likely a lot faster than any alternatives (I'm guessing), given they are in C. While I wasn't familiar with Neon before, I also really like YAML. But until there's a native PHP function to encode/decode it, I'd rather trade verbosity for speed. We're still much better off than XML. Ultimately though, my interest in the format is for portability and copy/paste, rather than manual editing. The goal with the form builder is that people will define this stuff interactively rather than by typing code. But it is going to be really handy to be able to copy/paste an entire form definition from one site to another.

The contact link was moved to the footer on the main site. But the forum template is different and so the contact link remains up there for now. We will get it more consistent when we launch the new site design.

Always happy to hear about a new language pack! You are correct -- start a new thread with the subject like this example: "English (en-US)" in the forum Soma linked to. Let me know if I can be of any help.

Got it setup here: http://wiki.processwire.com Nothing there yet but a blank MediaWiki. The access to it should be wide open, so Nico and anyone that wants to experiment, have at it. Let me know anything I can do or setup on this end. Thanks, Ryan

You guys got me thinking about this form builder and now I can't get my mind off it. I've taken a look at Netcarver's and Zend's form classes, and both look awesome. I'm particularly impressed by Netcarver's system and hope to be putting it to use sometime soon. Focusing on this a lot the last few days also made me realize that a PW formbuilder and the existing Inputfields have a lot of common ground. Enough so that it probably doesn't make sense for a PW formbuilder to venture outside of that. But it does make sense to upgrade PW's Inputfield system to make it more flexible consistent with the needs of a formbuilder. It's easier to maintain and support if there is one system rather than two. It wouldn't replace a system like Netcarver's or Zend's, but would provide a good middle ground for the less complex form needs. As a first step, I figured I'd see how well Inputfields would adapt for the sort of portability a formbuilder would need. The goal was to be able to take an array or JSON string, and have it render as a form using PW Inputfields, as they are now. This is something I'd not tried before, but the first step we'd need in order to easily store a form schema for a form builder. A small 20-line recursive function takes that array and dynamically creates a form composed entirely of PW Inputfields. All that's left to do is call $form->render(); I built a small test form and had success with it. Yesterday a friend needed help on a larger form, so decided to put the strategy to work there too. Here is the result. Not a pretty form by any stretch, but I was happy with how easily it all went together, and now getting me enthusiastic about going further with full blown form builder. As an example, here's the PHP array schema for my test form: $formArray = array( 'personal_info' => array( 'type' => 'Fieldset', 'label' => 'Personal Information', 'children' => array( 'first_name' => array( 'type' => 'Text', 'label' => "First Name", 'columnWidth' => 50, 'required' => true, ), 'last_name' => array( 'type' => 'Text', 'label' => "Last Name", 'columnWidth' => 50, 'required' => true ), 'email' => array( 'type' => 'Email', 'label' => "Your Email", 'columnWidth' => 50, 'required' => true ), 'phone' => array( 'type' => 'Text', 'label' => "Your Phone", 'columnWidth' => 50, 'required' => true ) ) ), 'customer_feedback' => array( 'type' => 'Fieldset', 'label' => 'Share Your Feedback', 'children' => array( 'store_location' => array( 'type' => 'Select', 'label' => 'What store location did you visit?', 'options' => array( 'ATL' => 'Atlanta, GA', 'CHI' => 'Chicago, IL', 'NYC' => 'New York, NY', 'SFO' => 'San Francisco, CA' ) ), 'would_visit_again' => array( 'type' => 'Radios', 'label' => 'Would you visit that location again?', 'options' => array( 'Y' => 'Yes I would', 'N' => 'No I would not' ) ), 'comments' => array( 'type' => 'Textarea', 'label' => 'Comments or Questions?', 'description' => "We'll respond right away!", 'rows' => 5 ) ) ), 'submit' => array( 'type' => 'Submit', 'value' => 'Submit Your Feedback!' ) ); That schema can be converted to/from JSON just by calling json_encode/json_decode on it, and gives us exactly the portability I'd want out of it. Given that this can be translated to a full form of Inputfields with a tiny function (arrayToForm), I figured that's a great first step towards an interactive formbuilder. Here's what the template code looks like: $form = arrayToForm($formArray); if($form->isSubmitted()) { $body = "<html><body>" . $form->renderValues() . "</body></html>"; $headers = "Content-type: text/html; charset=utf-8\nFrom: " . $form->get('email')->value; mail('me@domain.com', 'Form Submission', $body, $headers); echo "<h2>Thanks, your form was submitted!</h2>"; } else if(count($form->getErrors()) { echo "<h2>Fix the fields in red and try again.</h2>"; echo $form->render(); } else { echo $form->render(); } That's how I'm doing it now, but stuff like the above would obviously be integrated into a FormProcessor class so that you only need to call 1 function to display/process a form, and you could store and browse the results in a DB rather than just emailing it. Inputfields need to be upgraded so that all the structural markup is customizable. I'd probably want the default render output to be structured around fieldsets rather than lists, and be something that one wouldn't necessarily need any prerequisite CSS/JS except for progressive enhancement. Other upgrades would be more validation options for the basic Inputfields. The nice thing is that any upgrades would benefit all of PW, not just the formbuilder. The next test/proof-of-concept will be to make the creation of that $formArray interactive from the admin (with a Process module).

Sounds like you are on the right track with this Marc. I think PW should be a great way to construct a family tree. I agree that a Page reference would be the best way to identify any relations that don't follow the parent-child structure.