ryan

Well I think in this case, it's just that PHP doesn't have a built-in translation engine for this stuff. Functions like strtotime() do recognize English month names and such, but I think they are really intended to translate the most commonly used date strings to unix timestamps (most of which are digit based). It would be like it was/is in 2.2.9, as I think English is the default. Maybe I can just put in a note there, along the lines of "Warning: in languages other than English, stick to digit-based date inputs as only English month names are recognized in string-to-time date conversions." … or something like that

Not a poke at all. Right now I'm focused on getting 2.3 out and some client work, so not yet at a point where I can get into development for this. But these are all good ideas that we'll get into soon. I enjoy reading this stuff and then letting it marinate on the mind for awhile. Keep the conversation going. Once I get to a place where development is near, my posts will make yours look like short posts.

When you are manipulating a page for the purpose of saving your changes via the API, then you want to make sure that the output formatting state is OFF. When output formatting is OFF then your images field will always behave as an array. The single-image reference (with setting 1) is primarily for front-end syntactic convenience so that you can do echo $page->image->url rather than $page->image->first()->url. But behind the scenes, it's still always an array. This reveals itself when you try to set a value to it and output formatting is on, for instance. But in general, it's not good to set any values you intend to save when output formatting is on.

Btw, for anyone else trying to install Pear/PHPUnit on the latest MAMP (and possibly other recent versions), Nik's install instructions don't seem to work, at least they didn't for me. I think it's because MAMP has it's own [already installed] copy of Pear separate from OS X's copy. The very last entry on this page at Stack Exchange worked for me. It's the one answered Oct 9 '12 by Allen Hurff. Failed asserting that actual size "two words" matches expected size "one word".

Thanks Nik, this is fantastic! I'm already using and benefitting from it here. Just fixed two PW bugs, as you posted on the GitHub issues report. It's so nice to be able to run this to locate bugs and inconsistencies, and even better to run again after fixing them (to make sure some new problem wasn't introduced). Thanks again for your great work on this.

Take a look at this old thread too--might be similar to what you are trying to do: http://processwire.com/talk/topic/28-having-multiple-databases-hacking-pw2-to-work-on-two-different-servers/

It doesn't look to me like you are sending your query (q variable) through the ajax request? I'm guessing the code above would just retrieve the URL /busqueda/ with no query.

I agree it would be nice, but I don't see a simple solution to this one. The code that's tracking the changes doesn't know anything about multi language fields.

What do you think--better to leave out the jQuery UI datepicker translations to avoid this issue, or is it worth the compromise?

We do need to setup something like this, and hopefully will soon.

I honestly haven't tried it yet. But if for some reason it doesn't work, I'm sure I'll be able to make it work pretty easily.

At present, tabs aren't designed for inline use like this. The jQueryWireTabs module is largely in JS and I'm sure it's possible. But would probably require a major rewrite of the module to support that need.

This one is kind of hidden in the docs, but should provide more answers too.

See the blog profile which demonstrates a tag system.

LinkMonitor won't be included in 2.3. It'll remain a separate module. I've not yet released it because I think there's a better way do accomplish what it is doing... just haven't figured it all out yet.

Only non-zero values are stored. It removes zero-based values before saving them (less storage redundancy). In the case of the field you mentioned, "100" means "100%" which means "full-width". We actually store that as 0, since it is the default value for inputfield width. So in this case, it's not being stored since it is the default when it hasn't been specifically set. It should, but I've not confirmed that. This is one case where it doesn't matter to PW much because it saves them as a group either way. So maybe it's not a good thing to rely upon here, unless you can test ahead of time to make sure it's reporting them how you want.

The simplest way would just be to edit the table in phpmyadmin and add a 'unique' index to the 'data' column. But I think what we'll do is either offer this option on the Text fieldtype or have another [similar] fieldtype that already has the unix index built in. In this case, the Inputfield probably wouldn't get involved in it since the uniqueness would be enforced at the DB index level. Though the Inputfield would still be the one reporting the error when it occurs.

Thanks for the thinking here, these are all good ideas. We'll definitely want to expand upon the image options in one or more of these ways soon as bandwidth allows.

Radek, all the text you mentioned is now translatable. Also, the issue that caused it to miss text in Inputfield.php and Fieldtype.php should now be fixed as well (dev branch). Please confirm when you get a chance.

This is now fixed on the dev branch.

If you are actually inputting your dates with translated month names or the like, I don't know of a way to have the system reverse-translate it back to English so that PHP's strtotime() or date_parse_from_format() can understand it. If using multi-language, I think you need to stick with a digit-based date for the input side. Or if you prefer, you can just specify digit-based for your non-English languages by editing the date input format directly from the field settings. If this was working on a previous version of PW, I don't know how it was. The difference in the datetime field between 2.2.9 and 2.2.12 (current dev) is that the jQuery datetpicker language packs are present in 2.2.12. Perhaps they shouldn't be for this reason, though I included them thinking it would be worthwhile for the translation of the widget itself.

Thanks I can reproduce that and will figure out what it is.

What is your date input format string?

Thanks for the report Soma. Can you clarify what you mean by "not include string dates"? Maybe a screenshot of your date field 'details' and 'input' tabs would be good to see.

Someday I hope to have these functions more scalable so that they don't require being in-memory to perform their jobs. It's a tricky balance, having a large group of pages that can be sorted by anything, and then finding the current page's place within it, without being in memory. But we will get there.