ryan

It's a bug. Thanks for finding this, and for the excellent description on how to duplicate it. I was able to duplicate easily, and have committed a fix to the source. This bug has apparently been there since the beginning. I'm guessing not many have used manual sorting with pagination, which is why it's not turned up earlier. Glad to have this one fixed--a particularly annoying bug for sure. Sorry for the inconvenience it caused you. Please let me know if the fix does or doesn't resolve it from that end too.

There's still some bugs in this, as you found. I've got this on my issues list, but just haven't had time to fix it yet. Hopefully will have this resolved soon.

I can duplicate that too in Chrome too (and not in Firefox or Safari). While back buttons are generally evil in web apps, that's definitely not an expected behavior. Not sure if this is a bug in Chrome or what it is, or if there's anything we can do about it. It's basically interpreting the code wrong. Will do more research. Let me know if you can think of anything too.

That's not a problem. Technically it's no different than any other link. One thing you may find useful is to do a $session->redirect() to another page immediately after a login or logout (and of course before any output). That way you are starting on a clean slate and don't have to think about the state of the $user API var.

The module isn't intended for non-interactive use. However, the PW API certainly is (and LazyCron), and pretty clean and simple for doing stuff like this.

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.