ryan

This is great, thanks Jasper! Question for you guys: how far should we take the translations? Do you want the other parts of PW admin included in translations like: Setup > Fields Setup > Templates Setup > Languages Modules Access Or is it better to just keep the basics translated, like the things we would have our clients use? Basically, I want to keep the scope of it small enough that people can add languages really easily. Also want some flexibility to keep adding improvements in the Setup sections without creating work for translators every time I add/update something. But maybe that's just the nature of it. There is potentially a large amount of translatable text, especially in the Setup sections (Fields/Templates). I'm just trying to determine if these parts should be included in the translations or not.

I agree, I think this looks like a great addon to the datepicker. If anyone is interested in implementing this, please go ahead and let me know how I can help. If not, I will plan to implement as soon as there's time to do it.

Thanks, just added my modules to this too.

Statestreet, I just realized I didn't have this on GitHub, so I posted it to there, just in case you've got an earlier version. Here is the version that I am currently using on processwire.com for the Twitter feed that appears throughout the site: https://github.com/ryancramerdesign/MarkupTwitterFeed I'm wondering if your PHP might have allow_url_fopen disabled? You can find out by looking at your phpinfo(), i.e. put this on your server in a PHP file (like test.php) and load in your browser: <?php phpinfo(); I am guessing that you might have the allow_url_fopen option disabled, and that would prevent this module from being able to load the RSS feed. If you find that the option is enabled, then next check your Twitter RSS URL. Logout of Twitter and see if it still works? If I recall, some of Twitter's RSS feeds don't work unless you are logged in with the same browser you are retrieving them from, and you may have to enable access to it somewhere in your Twitter settings... it's been awhile since I've looked at this, so not positive what the current deal is there. But something to look at. Please let me know what you find.

Looking fantastic Soma!! You went further with the number of items hidden in 'advanced' than I was originally thinking, but now that I see it, I like it, and it makes sense. Creating, modifying and saving items really is more of an advanced thing, so I think your selection of what should go where is very well crafted. When in 'simple' mode: what do you think about all the sections that have advanced items ending with a tiny 'more' link or something like that? That way, one could look at all the $page options (for instance) without expanding all the advanced options for everything else. It would also make it clear that there is more depth to the cheatsheet for someone that might miss, or not understand what the 'advanced' option is at the top. I'm thinking these options below might fit better under 'advanced'? $page $page->next; (because one has to be careful with next/prev and large groups of pages) $page->prev; $page->next(); $page->prev(); $page->setOutputFormatting(); WireArray $a->getArray() (because rarely used) $a->getKeys() $a->getValues() Selectors: start=n (used more by system than user) end=n (rarely used) include=all include=hidden check_access=0 children.count=n created=timestamp (because these were advanced in $page section) modified=timestamp created_users_id=int modified_users_id=int $user $user->pass (because only useful for setting value) $input $input->get["name"] (because no need to list 3 ways of same thing in 'simple' mode) $input->post["name"] $input->cookie["name"] $session $session->getAll() (because rarely used) Lastly, what do you think about having the direct access get/set mentioned in $page like it is in $session? Maybe people already assume this, but I wasn't sure. $session->$name = $value $value = $session->$name

Thanks Soma, I tried to install and test this. While I can't get the module itself to work yet (getting some errors) I am seeing the proper load order for it's js file when viewing the 'data tables' page and looking at the source. I am wondering if this module ever had autoload enabled? The autoload setting in PW's modules table will be according to what it was at the time of installation. So if it was autoload at one time and you changed it, PW might not realize it's no longer autoload. If you view the modules table in the DB (via PhpMyAdmin) or the like, and locate the ProcessDataTable in there, what does it have for the 'flags' column? It should be a '1'. If it's a '2' or a '3', then it's autoload. If that's the case, try changing it to a '1' manually, or just uninstall and re-install the module from PW admin. Let me know what you find here...

You caught me! ;D Just checked, and you are right it looks like the files do not show as UTF-8 when I load them in my text editor (mine show Mac OS roman encoding). I don't really know why because they are saved with nothing but PHP's file_get_contents() and the data in there is UTF-8. I'm guessing the file has no explicit encoding and it's just showing up as whatever is one's editor default (?). I suppose it doesn't really matter if one doesn't need to load the JSON file in a separate editor, but would like them to be explicit about the encoding if possible–just not yet sure how. The only thing I can find in the file_put_contents user comments at php.net (for "utf") is this: <?php $myFile = 'test.txt'; $myContent = 'I love PHP'; file_put_contents($myFile, utf8_encode($myContent)); But that doesn't really help us, because utf8_encode() is for converting ISO-8859-1 encoding to UTF-8, and we're dealing with text that is already UTF-8 encoded.

If I understand correctly, you want the code snippet you pasted to appear at some place in your bodycopy that you designated. This is something that I do regularly with both images and fields. I tell the client to type either the word "images" or "files" in it's own paragraph with nothing else, and then all of their files or images will appear there in the right order with description, etc.. Here's the code I use to do it: <?php function bodytext($text, $page) { if(strpos($text, '<p>files</p>') !== false) { $out = ''; foreach($page->files as $file) { $out .= "<p><a class='file file_{$file->ext}' href='{$file->url}'>{$file->description}</a></p>"; } $text = str_replace('<p>files</p>', $out, $text); } if(strpos($text, '<p>images</p>') !== false) { $out = ''; foreach($page->images as $image) { // make the image small enough to fit bodycopy column, if it's too big if($image->width > 500) $image = $image->width(500); $out .= "<p><img src='{$image->url}' alt='{$image->description}' /><br />{$image->description}</p>"; } $text = str_replace('<p>images</p>', $out, $text); } return $text; } ?> <!-- later on in your code when you output the bodycopy --> <div id='bodycopy'> <?php echo bodytext($page->body, $page); ?> </div> I've done this on a couple sites now, and am thinking I should just make it a Textformatter plugin or something.

I've tried to duplicate here this morning, but still can't. Can you tell me if I'm missing any parts necessary to duplicate? Here's what I did: Copy the code you pasted to create ProcessDataTable.module, and also created an associated ProcessDataTable.js file with this: $(document).ready(function() { alert('test'); }); Then I put those two files in this directory: /site/modules/ProcessDataTable/ I installed from the Modules menu. Then I went and created this page in the admin: /processwire/test/. I select ProcessDataTable for the 'process' field of that page and save. Now I have a 'test' menu item in my admin top nav. If I click that page, I get the test alert. If I view the source, I see ProcessDataTable.js loading after JqueryCore and JqueryUI, as they are supposed to. Are there any parts I'm missing? For instance, I'm using the default admin theme. Do I need to install a different admin theme to duplicate? Is it possible there is some other autoload module calling upon ProcessDataTable in your case? Thanks, Ryan

There are a way to do it with TinyMCE only (using styleselect in the buttons1, using theme_advanced_styles and modifying TinyMCE content.css), but I think it's simpler just to apply it at render time in ProcessWire, like this: $page->body = str_replace("<pre>", "<pre class='brush: js'>", $page->body); You could do that before outputting your $page->body field.

Creating your own login template is a pretty simple thing. I recommend creating a template called "login" and putting the following in it: <?php // $out is where we'll keep our output $out = ''; // $form is where we'll keep our custom login form $form = " <form action='./' method='post'> <p><label>Username <input type='text' name='user' /></label></p> <p><label>Password <input type='password' name='pass' /></label></p> <p><input type='submit' name='submit_login' value='Login' /></p> </form>"; if($user->isLoggedin()) { // user is already logged in if($input->get->logout) { // page was accessed with ?logout=1 GET variable, so log them out $session->logout(); $session->redirect('./'); } else { // tell them they are logged in and how to logout $out = "<p>You are logged in. <a href='./?logout=1'>Logout?</a></p>"; } } else if($input->post->user && $input->post->pass) { // user submitted the login form if($session->login($input->post->user, $input->post->pass)) { // user was authenticated and logged in $session->redirect('./'); // or redirect to your members-only page } else { // the login failed $out = "<p class='error'>Login failed</p>"; $out .= $form; } } else { // user arrived at login page for first time $out = $form; } include("./head.inc"); // your site header, if applicable echo $out; include("./foot.inc"); // your site footer, if applicable Then assign the above template to your page, and you are set. Another approach you can take is to use PW's existing ProcessLogin module (the same one used by the admin). This takes less code as PW handles creation of the login form and the login logic. But you'll have to use and style PW's login form rather than your own. Here's how to create a template using PW's ProcessLogin module: <?php $out = ''; if($user->isLoggedin()) { // user is already logged in if($input->get->logout) { // user asked to logout – logout request via URL: ./?logout=1 $session->logout(); $out = "<p>You have logged out</p>"; } else { // user is logged in, give them a message or redirect them $out = "<p>You are logged in. <a href='./?logout=1'>Logout?</a></p>"; // or redirect them to your members-only page: $session->redirect('/path/to/page/'); } } else { // user is not logged in. present the login form from ProcessLogin module, // along with any system notices to accompany the process. $process = $modules->get('ProcessLogin'); foreach(wire('notices') as $notice) $out .= "<p>{$notice->text}</p>"; $out .= $process->execute(); } include("./head.inc"); // your site header, if applicable echo $out; include("./foot.inc"); // your site footer, if applicable

Slkwrm, Diogo–nice work! Just tried out both and they work great. Thank you for all of your efforts in doing these translations. I must say, Russian is another very cool looking language to me, perhaps because it's so completely different from English (no landmarks for an English reader at least). The only time I saw Russian language as a kid was watching/reading about space programs, nuclear submarines, etc. So it brings me back to that when I see it in ProcessWire–fun and cool to see. Are you saying that you want to use an encoding other than UTF-8? I think that UTF-8 is the only encoding that will let us be language neutral in ProcessWire itself. But any tool that will let you change the encoding of a text file should let you convert to and from it from the JSON files. For instance, on OS X, I use a tool called TextWrangler (free version of BBEdit) that lets me convert a file from one encoding to another pretty easily. Just be sure to convert back to UTF-8 before putting in ProcessWire. Are there any Cyrillic symbols that you aren't able to use in PW/UTF-8?

Sounds good, let us know how it goes. I'm suspicious they are using eval() since they've changed the PHP tags (almost certain of it), so it may slow things down in PW a lot, but give it a try and let us know how it works.

Just to confirm, the code snippet you posted is reproducible with it's JS loading before jQueryCore? I will give a try here and get a fix going next week. In the short term, I'd suggest renaming your JS file, and instead loading it like this: <?php public function ___execute() { $this->config->scripts->add($this->config->urls->ProcessDataTable . 'your-js-file.js'); // .. then your code here } I'm hoping that might provide a temporary fix in your case, but since I don't yet understand why it's loading jQueryCore after yours, I can't say for certain. But I am certain we'll be able to find a fix next week.

Soma–sounds good. I'll plan on adding the appropriate hook in ProcessPageList next week in the dev branch, and we can do more testing then.

Currently it requires at least one ASCII letter, whether a-z or A-Z: if(!preg_match('/[a-zA-Z]/', $value)) $this->error($this->_("Password does not contain at least one letter (a-z A-Z).")); If it detects an error in the password, it makes it blank, requiring you to re-type it. I'm thinking I should update that preg_match to be a "\w" (any word character) rather than a-zA-Z, and that would probably solve this.

Here's how to create a new field from your install function: <?php public function ___install() { $field = new Field(); $field->type = $this->modules->get("FieldtypeDatetime"); $field->name = 'publish_from'; $field->label = 'Publish From Date'; $field->dateOutputFormat = wire('config')->dateFormat; $field->dateInputFormat = wire('config')->dateFormat; $field->datepicker = 1; // if you want datepicker enabled $field->defaultToday = 1; // if you want dates to default to today $field->save(); // repeat for publish_until field } public function ___uninstall() { // only do the following if you want to uninstall the fields that were installed // this may be one thing that's safe to leave to the user $field = wire('fields')->get('publish_from'); if($field && $field->numFieldgroups() > 0) throw new WireException("Can't uninstall because field publish_from is still being used. Please remove it from any templates."); wire('fields')->delete($field); // repeat for publish_until field } Creating tabs is a little different because not only will you have to create the field, but you'll have to add it to fieldgroups. And I'm not sure how you determine what fieldgroups it should be added to. I think this is almost something that is better to leave to the user... or handle on the module's config settings, where they can check boxes next to the templates they want to have scheduled pages. If you are interested, I can help with that next week – my wife gives me crap about being on the computer on the weekend.

Great idea Nico, thanks for getting the ball rolling on this! I've been thinking more and more about this modules directory, and it looks like we're both on the same wavelength here. I think your spreadsheet gets it nearly perfect, just a few tweaks I might suggest – let me know what you think? 1. Ultimately I want people to be able to browse by module type. So I'd suggest adding a column for module "Type" and optional "Subtype". Types would be: Process, Text formatter, Input field, Field type, jQuery, Markup, Page, Language, and Other. If it falls under "other" then, they would specify their own Subtype. I'm not positive this is the best categorization, but it's the only one we've got so far. If anyone has any ideas for a better categorization, feel free to suggest things, as the module directory may benefit from a different categorization system. 2. Instead of just Download URL, I'd suggest these 3: GitHub URL (you already have this, but we'd require a GitHub URL) Direct download (ZIP file) URL, regardless of where it's hosted (GitHub or otherwise). Eventually I want people to be able to install modules directly from the PW admin, so having a direct download URL will facilitate that. Forum/Support URL (you already have this, but we'd keep the URLs columns all together) 3. In addition to 'description', have an optional extended description. Perhaps the two could be called 'summary' and 'body' or whatever you think is best. I'm not suggesting this to replace the "how to install" that you already have–keep it, it's great. I'm just wanting for people to have the option of including an extended description for the module's landing page. Whereas, the short 'description' or summary would appear in the module listings. 4. I like what you've done with having the creator name and forum name. Just wondering if we could split them in two columns: creator full name, and creator forum name (if multiple, then they would be split by commas). Ultimately I want people to be able to add and manage their own listings, and PW's going to need easy access to their forum name for authentication. We could get it in the parenthesis like you have, but thinking it might be even better just as separate columns… but you decide.

Christoph, that plugin formmailer referred to is the way to go for now, but I do plan to make it built-in in the near future.

I actually didn't understand it myself until I ran across the same word needing to be repeated in multiple places in the search module: 1. The "Search" placeholder text in the input[text] at the top right corner 2. The "Search" headline at the top of the page 3. The "Search" submit button in the sidebar search So it's the same word repeated 3 times in the same file (meaning, in the same textdomain). All is well and good in English because it's the same word and who cares if it's repeated. But when it comes to other languages, text used in a headline, text used as a placeholder in an input, and text used in a button may need different translations. So this "disambiguation by context" means we can use the same word repeatedly and not have them all use the same translation. So here's what's happening in ProcessPageSearch: $this->_x("Search", "headline"); $this->_x("Search", "input"); $this->_x("Search', "submit"); If some language needs those 3 to result in different translations, they can, thanks to disambiguation by context. It's a small detail, kind of like plurals, but I think its good to get the details right, even if they don't come up very often.

Nice work Antti! I'm amazed how quickly you got this done, you guys are all amazingly fast with this stuff. I must admit, Finnish is one cool looking language. I love the translation for "Access" – it's just nice to look at ;D Käyttäjähallinta That seems like a good idea. This one is possible, but a little more tricky than other parts of PW. This is because none of this data is in the database, it's all in JSON files on disk. Kind of like with gettext how all its data is in those .pot files or whatever they are called. Though in our case, JSON files are just text, so solutions are within reach whether based on grep or just loading the whole file and matching a string with stripos. If this is a recurring need we'll find a good way to implement it.

Great! Glad that was it, thanks for testing it.

Nice work Nikola! What script are you using for the dropdown menus?

I think that was it, the "\" vs "/" on windows vs. unix. Can't believe I didn't think about that before. I just committed an update that accounts for that, and am hoping this might fix it. Please let me know. Thanks, Ryan

Thanks for testing. It's probably something stupid on my part like forgetting to account for the differences in Win vs. unix slashes. I'll do more research here and track down what the issue is and post an update. Until then, I also wanted to show you how easy it is to use the translation functions in your own site templates. Here is a short video that demonstrates how to do it: http://processwire.com/videos/processwire-language-translation-example/