ryan

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.

Good idea Nico. I'm happy to setup subdomains as needed.

I think that these are all great ideas. Though I've always been of the opinion that an image should belong to whatever page it is used on. That comes from my own experiences with the sites I build, and these sites typically don't need to share specifically named individual assets on multiple pages. Actually, they share quite a lot, but in a different way. When they share assets, it's with a relationship like "pull the first image from these pages" rather than "show this specific person's photo from that page". ProcessWire works especially well with the "pull the first image from these pages" type of relationship. But the problem with "pull this specific person's photo from that page" relationship is that if the owning page deletes the image or the page, then the other page referencing it has lost it. This isn't usually a problem for me because the instances where I need to share an image in that way are pretty rare. Basically, the only instance I can think of is in TinyMCE when you want to use the same exact photo for placement in more than one page. It's a nice thing to be able to do on occasion, but it's problematic to scale because the more you do it, the more fragile things become. Is this type of image relationship something that people are doing a lot in ProcessWire? If so, is that really what they should be doing? I'm not sure… but if it is, we'd probably want to solve the inherent fragility of that type of relationship before building lots of features to facilitate selection of images from other pages.

I think it's a good feature to have. There are times when I use an ID get a $pages->get(123) and it always demands a comment to describe what the ID is. Whereas I much prefer "self describing" identifiers, like paths. But of course, it's possible for a path to change (for some sites). I also agree it's not something that's needed in the core (or at least turned on by default), where we are trying to keep things simple and not introduce more new concepts for people to keep track of. But for regular users of PW, I can see this being a useful module to have. It would be particularly easy to implement too... basically just the FieldtypeText with a mysql 'unique' index on the data column. If we were implementing this, it might be nice to have 'id' and 'class' attributes supported by the fieldtype, for familiarity and consistency with what people are using in html/css. Then people could retrieve pages with selectors like "attr.id=form-builder" or "attr.class=beta". Though the 'class' one would be a little harder to implement than the id one, and it has a lot of crossover with selection by template, page reference, etc., so definitely not as useful as id.

You should be able to use the $field->getTableData() function. In addition to what is in $settings, it will also have a 'data' property which is an array containing any custom field settings. Let me know if that doesn't provide what you need?