ryan

Sure. Though it's a little problematic because in order to be complete, every single page in the site would have to be visited and have a cache file generated for it. It's certainly possible to do on your own, assuming you can easily visit every page in your site (i.e. it's not too big). But if I build it as a "feature", then it has to be scalable to very large situations… not sure I'm up for that.

Probably so, I agree. Though stepping back to the idea of unpublished users: they don't really have a purpose other than short-term, between page edits. When you create a user, it doesn't give you the opportunity to "Save and Keep Unpublished". So the only way that an unpublished user exists is in-between the time that you create a user on the screen asking for the name, and the time that you save the user after entering their email address, etc. Or if you create the user, and don't finish.

With multi-language page names, the beginning "en" or "de" segment (as examples) aren't technically necessary, as the language can be determined from the page names alone. But I understand it may still be desirable, so I'll be looking for ways to handle that. But as for $page->rootParent, you'd probably want $page->parents()->eq(2) instead. Also Page::rootParent is hookable. Though I don't really want people to have to think about these things. This could be done by adding checkbox or page reference fields to check which languages you want to be included in any given children() or find() results, etc., and then making use of it in your selectors. If that became desirable as a core feature, we'd probably implement it in some way similar, behind the scenes. I will probably have to set it up to override the user's language settings when the page names module is installed.

Be sure to grab the latest, as I updated many things this morning. I haven't noticed this level of difference yet between TinyMCE and CKEditor. But if this becomes a common feeling among ProcessWire users, then we could always switch out the core default from TinyMCE to CKEditor. Though I would like to maintain them both either way. I noticed CKEditor doesn't seem happy to paste text without inserting a bunch of style attributes into it... which is annoying. But I'm sure there's a way to configure that out of there, just haven't figured out how yet. The current dev version of CKEditor does support allowed content rules in a manner similar to TinyMCE, but the stable version [that we are using] apparently does not (?).

CKEditor for ProcessWire CKEditor is a web text editor like TinyMCE. This module can be used anywhere TinyMCE can be used in ProcessWire and it is generally considered one of the best web text editors out there. TinyMCE and CKEditor have always been the two big leaders of web text editors, and they've been equals for many years. Though lately it seems like CKEditor might be a little ahead of TinyMCE in some areas, so I thought we should give people the option of using CKEditor with ProcessWire. CKEditor has a nice inline mode that is desirable in the page editor when you may have lots of rich text inputs. The reason for this is that the page editor loads a lot faster. If you have this need, this would be one reason why you might want to use CKEditor over TinyMCE. Some also prefer CKEditor for other reasons. For instance, @apeisa prefers the table controls in CKEditor to TinyMCE's. Here are a few notes about this module: You already know CKEditor–it's what this forum is using. Though the version included with ProcessWire's module is significantly newer. It is currently beta test. You are advised to test thoroughly before using it in production. You may very well run into bugs, in which case please let me know so that I can fix. It is tested and confirmed compatible with both repeaters and multi-language support. It is now fully hooked into our link and image systems, like TinyMCE. Thanks to Antti for helping with the image plugin. If you want to use the inline mode, you'll need to install the HTML Purifier module first. The toolbar is fully configurable. It is multi-language ready and all text in the module is translatable. Like with TinyMCE, the module optionally supports definition of custom plugins and content.css file. How to install Copy all the files from this module into: /site/modules/InputfieldCKEditor/ Login to your admin and go to Modules > Check for new modules. Click install for InputfieldCKEditor. Now go to Setup > Fields and locate a textarea field that you want to use CKEditor (or create a new textarea field). When editing the settings for a textarea field, click the Details tab. Change the Inputfield Type to CKEditor and save. While still editing the field settings, click to the Input tab for CKEditor-specific settings you may optionally configure. Download ProcessWire Modules page: http://modules.processwire.com/modules/inputfield-ckeditor/ GitHub Repo: https://github.com/ryancramerdesign/InputfieldCKEditor Screenshots Screenshot of regular mode: Screenshot of inline mode, combined with multi-language fields:

The project you are doing does sound like a good fit for PW. I'm not sure I totally understand what a slot-picker is, so it might help to see a screenshot of what you are trying to achieve. But if it's something you will ultimately relate to pages, then need only make an Inputfield module that extends something like InputfieldSelectMultiple. If it's something where you want to handle the data storage separately, then you'll need to make both a Fieldtype and related Inputfield module. But give us some more details on this slot-picker (screenshot, if possible) and we can take it from there.

When the cache is fully populated, you could do this. You could literally take everything in the /site/assets/ProCache/ dir, move it to the root on another web server and it would function statically. You would also need to have your other static assets copied over too, which I think would be limited to these dirs: /site/assets/files/* /site/assets/templates/styles/* /site/assets/templates/scripts/*

Thanks for confirming. A fix has been pushed for this.

Adding this to your .htaccess file might do the trick too: AddDefaultCharset UTF-8 Make sure your document is also specifying a <meta charset>.

Please send a cold keg of Unibroue La Fin Du Monde, and I'll have my tap ready. Just kidding, but that's one of my top 3 beers and has been for a long time. Canadians know how to make some damn fine beer, that's for sure. Luckily it's easy to get around here. A good thing, because Georgia has some kind of laws about shipping beer (to protect the poor beer/wine distributors).

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.