ryan

I'm pretty close to having native core support for multi-language page names. It's something I wanted to add originally in 2.1, but just didn't know exactly how without adding lots of overhead. After marinating on it for a long time, an easy way to accomplish it finally became apparent. A nice thing about it is that it does it with near zero overhead. It won't be as fancy as the LanguageLocalizedURL module, but it should be good for people that have relatively simple needs. It's the one feature that we were missing that would really let the multi-language fields sing, and it should lead the way for making more fieldtypes multi-language capable. It works by enabling you to specify an alternate name for each page, for each language. When a page is accessed at its alternate URL, then the language is automatically detected and set for the request. Combined with multi-language fields or multi-language alternate fields, it provides a full multi-language solution without need for multiple trees or having to use any code to set the language. It's not the right solution for all situations, but for some situations, it'll be quite nice. Lets say you've got the page /about-us/contact/. For the "about-us" page you've set the Spanish language name to be "quienes-somos", and for the "contact" page you've set the Spanish language name to be "contacto". When the URL /quienes-somos/contacto/ is accessed, it's technically referring to the same page as /about-us/contact/, except that the user's language is automatically set to Spanish, and thus any multi-language fields output in Spanish. Calls to $page->url on any other pages also output the Spanish URLs. You don't have to define alternate labels for all pages if you don't want to. So long as there is just one of them in the URL (like in the rootParent, for example) then it'll be able to detect the language automatically. In order to avoid problems with having multiple URLs displaying the same content, it doesn't let you access the page with a URL like /about-us/contacto/ (English and Spanish mashup), because both of those pages have their names translated. So if you accessed such a URL, it would 301 redirect to the Spanish version. Here's a screenshot that might help to explain how these things are defined. This will be committed to the core within the next few days, as part of the LanguageSupport group of modules, but I'm going to leave it as an uninstalled alpha then beta module, until ProcessWire 2.4.

It doesn't matter. Though if you had multiple "sort=something" statements, then it would consider the order of the sort statements. Meaning, if you had "sort=last_name, sort=first_name" then the results would first be sorted by last_name and then by first_name. Whereas "sort=first_name, sort=last_name" would do the opposite.

Great idea and module Nik! This will actually be quite handy on a site I'm working on right now.

Thanks for letting me know. I'll take a look at this. Though specifying "0" for either dimension means "keep it proportional", and that would take precedence. What were the original and target dimensions of the image you were seeing get upscaled?

While ProcessWire is more than a CMS, I still think CMS is the best way to market it. That's what our target market is searching for. And just because the term means different things to different people, ProcessWire still fits the actual meaning quite well: "content management system." CMF is perhaps an even better term to describe ProcessWire, but nobody is looking for that. We are #1 in Google for the term "Open Source CMF", and our analytics don't prove this to be a term that anyone is looking for. Whereas, "Open Source CMS" is a rather competitive term (and we usually appear somewhere on page 2 of the search results). Even though we are more than a CMS the way most people know it, I still think it's the term that connects with the broadest audience. People looking for a CMS find a great one with ProcessWire. And when they are ready to do more, they'll find ProcessWire to be a tool they can continue to grow with.

Strange I wonder what was blocking it from coming out of the trash. If it wasn't the family settings, I really don't know what it could be. But if you find it turns up again, let me know. Btw, when you said PDA, I thought you were talking about an old school mobile device or something.

Good idea Wanze. This would also have the benefit of excluding most crawlers from the counter. Though if a user really wanted to, they could manipulate the results, but of course they could do that either way. One question, which I'm sure has an obvious answer, but I don't know it. Would the $.post request hold up the page render, or would it occur behind the scenes?Basically I'm just wondering if the $.post should be done in a $(document).ready() rather than inline?

I'm looking for a Google Maps expert to work with on a maps project that would be built in ProcessWire. Most likely we'd use FieldtypeMapMarker. The coordinate data set currently consistents of a few hundred entries, though would grow over time. Each item in the data set has various meta data that we would just store with ProcessWire fields. I've built several of these types of things before, except that this one technically goes further with Google Maps than I know about. Some examples of needed functionality: When the user zooms out, large groups of markers need to condense to some other representation, like a single marker with a number in it (or similar). We would need a sidebar of categories and subcategories. The user can click any one of them to enable/disable the relevant markers in the map. The map would need to have a full screen option (like with a YouTube video). The map must be mobile friendly for those on cell phones, etc. If you have this type of expertise with Google Maps, please PM me. This would of course be paid work. I will share the full scope of the project with anyone interested and I would be looking to get an estimate from you. This project would move quickly and need to launch within a month from now.

Thanks again for making this. I have added it in the middle of the API navigation.

This is true. It's not currently possible. I understand there are some good use cases for supporting one level of repeaters within repeaters, so I'll be on the lookout for a way to support it. But for now, the best route to take for the use case you mentioned is to do it with pages instead of repeaters. Though in your case, I think the textarea option might be a good one since you only need a key and value. You could enter the variants like this: 5.99=Half order 6.50=Half order with cheese 9.50=Full order with cheese On your front-end, you could work with it like this: $variations = array(); foreach(explode("\n", $item->variations) as $line) { list($price, $label) = explode("=", trim($line)); // you could output the variations right here echo "<li>$label: $price</li>"; // or you could stuff them into an array for later use, like this: $variations[$label] = $price; } // how you might output the array, if preferred echo "<table>"; foreach($variations as $label => $price) { echo "<tr><td>$label</td><td>$price</td></tr>"; } echo "</table>";

In ProcessWire 2.3, The $config->userAuthHashType is only used as a fallback if bcrypt/blowfish isn't available. Anthony Ferrara's password_compat library is great btw. We are using portions of it in the current Password class. We may switch to using it in full once we're fully transitioned to PHP 5.3. He's one of those guys that the PHP community is very lucky to have. Brilliant coder, but also has the heart of the teacher and the ability to communicate complex things in a way anyone can understand (especially with his videos).

ProCache completely bypasses ProcessWire, so any code that saves a counter would not get executed. As a result, you probably don't want to cache pages (whether with ProCache or the built-in cache) that you need to execute the counter code on. This is one reason why using separate services or software for analytics is a good thing (Google Analytics, Piwik, etc.)

I love the name Soma. Great idea. Seems like we should link or mirror this like we're doing with the cheatsheet. Since I regularly add new hooks, how is it best kept up-to-date?

VHS vs. Beta, BlueRay vs. HD-DVD, etc. -- These are winner-takes-all markets. The CMS market is a totally different landscape. But I agree with the premise of marketing and the importance of getting the word out there. I also agree that we can learn things from the marketing of other related products out there. Though word-of-mouth is the best marketing there is, so I agree with Kunane that making the product (and support) the best it can be are great ways foster good word-of-mouth. ProcessWire is a community project rather than a business, so we don't have the marketing resources of for-profit businesses. But as we grow I think we'll have more and more resources to pursue new avenues of communication.

Thanks guys, looks like I broke that over the weekend, but the fix was easy. Now fixed.

I'm not familiar with the internals of the ProcessDateArchiver module, but is the page in question (or its parent, or its target parent) using a template that is related to the ProcessDateArchiver module?

In cases where a drag-drop isn't supported (like on a cellphone, tablet, etc.) you would edit the page, click to the "settings" tab, and change the parent from there. If it still doesn't let you put it where you want to, you may need to adjust the family settings of the relevant templates. Those family settings in each template optionally control where pages will be allowed to ultimately live or be moved to.

The "501 Method Not Implemented" concerns me a bit, as that sounds like maybe the server has some firewall, mod_security, or something specifically blocking file uploads. But before we look more at that, I would double check that your /site/assets/files/ really is writable. 755 permission isn't something that's going to work on every server. Also, when you transfer a file from dev to production, it's possible those permissions are lost, or are not consistent with the permission needs of the server. You might want to try installing a fresh copy of ProcessWire (dev branch) on the server in a subdirectory. When it reaches the "file permissions" section (same screen as DB config), see what it recommends as a starting point. You may ultimately have to adjust the permissions of the files that are in /site/assets/. Some FTP clients may provide the option to do this for you, in one shot. If you have SSH access, you can also do it easily with "chmod -R ...".

Are you actually trying to connect to MT's MySQL server from outside of MT's network? I'm guessing they don't allow outside connections to their MySQL servers. Actually, I'm almost sure of it, as I've tried before (though it was while ago).

You might need to switch to the dev branch to take advantage of that fix. In the field settings "details" tab, you'd set the API value to be "Single Page or NullPage" or "Single Page or boolean false", depending on what you prefer. Note that the autocomplete is built as a multi-page input, so it may still behave as such on the admin side.

Added to the wiki. Though not exactly sure how to categorize it… but we'll figure it out eventually.

Sounds good, makes sense to me. I will put in a todo in MarkupCache to support the serialize/unserialize where appropriate.

Making ImageSizer::resize hookable seems like it's a good idea for this need. I will go ahead and make it a hookable method and should appear in the dev branch after I test a bit.

I don't build a lot of multi-language sites, so some others here may have better suggestions than me. But in your case I would probably build separate trees for each language. Then have some code at the top of your shared template file that sets the language consistent with the branch: if($page->rootParent->name == 'en') $user->language = $languages->get('en'); else if($page->rootParent->name == 'es') $user->language = $languages->get('es'); else if($page->rootParent->name == 'fr') $user->language = $languages->get('fr'); or better yet, if we can assume your language names and rootParent names will be the same, you could do this: $language = $languages->get($page->rootParent->name); if($language->id) $user->language = $language; For your categories, you would want to use a Page reference field. Add a text field to the category template that uses the TextLanguage field type. (You'll have to install the LanguageSupportFields module for this). Then every time you add a category, you'll have inputs for each of your languages. When the front-end of your site outputs this field, it'll pull from the correct language automatically.

While Soma is right that the only way to get 100% before and after everything that happens is to literally put it in index.php, there are a couple of hooks that may provide what you need. An autoload module's init() function is a good starting point, and ProcessPageView::finished is a good hook to end with.