ryan

Great tutorials and examples Joss! This would probably be a good addition to the Wiki tutorials too?

Antti, I think you should be able to just set that email field before you output your comments. I don't think you'd need any modules or hooks or anything like that. So lets say you had a field on your page called comments_email. You may be able to do something like this: if($page->comments_email) { $commentsField = $fields->get('comments'); $commentsField->notificationEmail = $page->comments_email; } echo $page->comments->render(); echo $page->comments->renderForm();

Arjen, you don't necessarily even have to create a module for this. You could just add a template, then create a page with it in the admin, like you would on the front-end of your site. This is something I often do just because it's sometimes quicker than creating a dedicated module. Adding a page in the admin can be technically no different than adding one on the front-end of your site. So listing all users could just be a matter of creating a template like below, and then creating a page in your admin: include("./head.inc"); foreach($pages->find("template=user, include=all") as $user) { echo "<p>$user->name</p>"; } include("./foot.inc");

It might be possible, I will look into it. One way you could currently accomplish it is by making a child page of the homepage that serves as the rootParent. Lets say you needed to support 3 languages, with English being the default. You'd give this single page the names "en", "fi", and "de" (to match up with your language names). The template would need no fields, and the template file would contain just this: $homepage = $pages->get('/'); $language = $languages->get(trim($page->path, '/')); if($language->id) $user->language = $language; echo $homepage->render(); In that manner, all of your non-default language homepages could be accessed at /fi/, /de/, etc. And you'd build your structure below that single language gateway page. You'd end up with URLs that are probably exactly what you'd want in a multi-language site, with no need to duplicate any pages. If you guys are interested, the LanguageSupportPageNames module is now committed to the dev branch. It's an early version only suitable for testing, so don't install on any production sites.

Here's a link to the CKEditor module work-in-progress if you want to try it out. I'm not yet using it in production, but it seems to work well locally on the sites I'm developing. https://github.com/ryancramerdesign/InputfieldCKEditor

HTML Purifier is an HTML sanitization and validation module for ProcessWire. It serves as a front-end to the HTML Purifier PHP library. From htmlpurifier.org: Usage: This module is something that you would use from a template file or another module. The syntax basically goes like this: $purifier = $modules->get('MarkupHTMLPurifier'); $cleanHTML = $purifier->purify($dirtyHTML); The default settings seem to be about right for most cases. However, you can also specify custom settings to HTML Purifier by performing set() calls before calling purify(). For example, UTF-8 encoding is assumed, so if you wanted ISO-8859-1 instead, you'd do: $purifier->set('Core.Encoding', 'ISO-8859-1'); About this module: The reason I made this module is that I'm currently working on a CKEditor module for ProcessWire. It supports a very nice inline mode that I'd like to use. But the problem with an inline mode is that the text you edit is real rendered HTML (rather than a textarea), so that could be a security problem (i.e. XSS). I researched into into how best to resolve that, and the HTML Purifier library kept coming up. So here this module is. The new CKEditor module will require it if you want to use inline mode. Download: GitHub: https://github.com/ryancramerdesign/MarkupHTMLPurifier Modules Directory: http://modules.processwire.com/modules/markup-htmlpurifier/

There will be a way to get URLs for the page in any language. I haven't yet figured out where to put it, but it'll be there. Of course, you can always do this too: $saved = $user->language; foreach($languages as $language) { $user->language = $language; echo "<li>$page->url</li>"; } $user->language = $saved; Probably what I'll do set set it up so that you can pass a context to $page->url, like $page->url($language); Overlapping will be okay, and I imagine necessary in some cases where a word is the same in two languages. So long as one of the parent names is language-specific, it'll still resolve to the right language. If there is a collision between the page and all parents, then at that point you would have to make something unique about the page's URL so that the pages don't have the same exact path. Homepage has no path, so there's nothing to trigger a language selection there. In a setup using multi-language page names, I imagine the homepage would either be 1) a gateway asking you to select a language; or 2) be presented in the default language with links to other languages. Homepages for other languages would have to be at some other URL, like domain.com/de/ or wherever you wanted it.

I've got a CKEditor 4.1 Inputfield pretty far along. I'm trying to duplicate most or all of the functionality we have in TinyMCE with regards to the link and image plugins. So far I've got the link one fully functional, and hope to have the image one wrapped up soon. The docs are nice to look at for CKEditor, but I haven't found them to be any more useful different than TinyMCE's. I still have to ultimately figure out how to do everything via the Chrome web inspector and "trial and error". Though part of this is because we use our own dialogs rather than the ones supplied with TinyMCE and CKEditor. I'm loving the inline mode (using it in the admin). I've got a couple dozen textarea fields to power on a single page. Using TinyMCE or CKEditor regular editing mode, it took several seconds of loading/initialization. I experimented with Redactor, which was quite bit faster for that, but still not perfect. Then I tried out CKEditor's inline mode and BAM! they all load in an instant. So CKEditor's inline mode seems to have some real benefits in speed… particularly if you need to power lots of rich text fields in 1 editor (like you would in a repeater, for instance). Or in my case, several repeater items, each containing TextareaLanguage fields for 6 languages… meaning, potentially dozens of rich text fields in 1 editor. So finding something that could do rich text editing quickly became a necessity. And it looks like CKEditor nailed it with this.

I think that technically multi-trees still provides for the most flexibility and will still be the right solution for many. There is kind of an assumption with multi-language page names that every page in the structure is applicable regardless of language. Also, I'm guessing that the LanguageLocalizedURL module will still be a good solution for many as well. But the truth is, I don't build a lot of multi-language sites, so I don't know all the scenarios as well as you guys. But I am building a multi-language site right now (that needs to support 6+ languages initially, with 17k+ pages), and the existing multi-language options weren't working quite right for this project, so decided to pursue this instead. You can use either. How you handle the URL segments outside of a page's actual path is up to you. As a matter of keeping it simple, I would probably stick to more abstract URL segments that aren't language specific. But your "page-name-en" and "page-name-de" as page names will set the language. I'll rely on you guys to tell me what I'm missing. I'll try to get this committed to the core later this week for anyone that wants to play with it. But I would hold off using it on production sites until we're further along with it. When the module is installed, every page in your site gets inputs for each language for the page "name" field (like in the screenshot). In order for the page to automatically switch languages based on URL, then the page itself OR one of it's parents must have the name defined in the target language. The URL is what ultimately triggers what language gets set to the user, and thus what language gets displayed in multi-language fields, static translations, etc. The behavior of it is basically identical to the existing $page->name field. In fact, it keeps the other language page names right alongside the 'name' field in the existing pages table. In this way, the data is searchable, selectable and loads with pages, without extra overhead.

Great site! The design really compliments the nautical/sailing photography quite nicely. It makes me want to go sailing. I wish I could… But we have no big lakes, rivers, or any large bodies of water in Atlanta… well except for in my basement when it rains.

Sorry if this is a dumb question. But are you using a browser that supports the HTML5 "number" input type? Does the issue only occur when you choose "number", or does it have issues saving when "text" is selected as well?

I think that traditional version control with Git or the equivalent is great for template files, front-end development files and your own custom modules. When it comes to defining the templates and fields on the admin side, it's better to do this from the admin rather than migrating SQL queries or the like. So someone in your team should be the gatekeeper for these administration resources.

I'm not surprised that the profile exporter module doesn't work with multi language fields just because it was written before multi language fields existed. Though it's not totally clear to me why it wouldn't work, since the multi-language values become part of the regular field data. I'll have to experiment with it and update the profile exporter module to support them. When you imported the profile, did it show the Languages module as arleady installed, or did you have to install it after importing the module?

I think this happens because the code that removes the fields from templates doesn't know anything about specific fieldtypes. In that respect, it's different than a delete action. I'll think on this some more and see if there's an alternate way.

When I'm installing to a new server where I'm not totally sure about the capabilities of it, I install a fresh/new copy of PW just to test and see if the installer complains about anything. That doesn't mean you have to use that fresh copy for the actual site, but it does give you a picture of potential issues that might need to be addressed on the server side. Based on the error message you got (a missing image) I would guess that not all the files made it over in the transfer, and it might be as simple as just attempting to transfer them again. However, the error you got was a Warning rather than a fatal error, so it shouldn't prevent the site from running. There's always a chance you were getting the same warning on your dev server, but didn't see it because debug mode was off.

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>";