Leaderboard

Quick 'n' dirty guide if you want a single page tree with the same content in different languages. The URLs will then look like example.com/en/my-article or example.com/de/mein-artikel 1:) Download and install ProcessWire 2:) Install the modules you find under the "Language" Tab. 3:) Go To Setup->Languages and add new languages. Please note, that the default one is also the default language of your site* 4:) For every field type text or textArea change the Type to TextAreaLanguage or TextLanguage. (e.G. body with TextArea becomes body with textAreaLanguage). You fields should now have multiple tabs for each language, if you edit a page. 5:) Go to the root page (/) and look under "Settings" Setup an URL for every language, e.g. en,de,ru,... . Looks like this: http://take.ms/34Tq5 6:) Create pages and fill in the content. You can build a front end language switch as described in Ryans API Language page. ProcessWire will take care of changing URLS (e.g. /en/example to /de/beispiel) and you can access the current language via $user->language; *It's possible later to define another language as the default language.

If you need the function multiple times in different contexts (templates, modules... etc.) then you can write a simple module. Calling a method in your module goes like this: $myModule = $modules->get('MyModule'); echo $myModule->myFunction(); Advantage: You have access to your module anywhere Module sample code: class MyModule extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'My Module', 'version' => 100, 'summary' => 'ProcessWire is awesome', 'singular' => true, 'autoload' => false, ); } public function init() { // Do stuff after an instance of this module is created } public function myMethod() { return 'yeah baby!'; } }

I'm not exactly sure what you're thinking "combine" means here, but this field does exactly what the description says; it grabs data from other fields, mashes it all together into one big blob of (JSON) content -- and that's just about it. One very simple (yet sometimes very practical) use case is if you've got, say, 15 different text fields and you need to find pages that contain value "john doe" in any of those. Instead of doing this: $john_does = $pages->find('field1|field2|field3|field4|field5|...|field15%="john doe"'); .. you can create a cache field, select all of those fields to be cached in it, and then do this: $john_does = $pages->find('my_cache_field%="john doe"'); Not only does this look clean, in certain situations it can wildly improve query performance.

I have no problem with spaces in passwords. Can't say I've ever thought to put spaces in passwords, but it makes sense. I'll update to support that the next time I'm in the code for that module. As for logging in with email address, PW uses the username as the unique key for all users. Users are pages, so this is for consistency with the pages system as a whole. I think maintaining this consistency is preferable in keeping the whole thing as simple as possible. Not to mention, 'name' is a built-in property of every page, whereas 'email' is just a custom field in the template (it's technically possible for it to not exist).

Yeah I was thinking Ipa's suggestion could be handled at the field configuration level when revealing the "pass" field which comes by default. I guess that's probably what you're saying craig but one level lower?

The Holy Grail would be to surface the complexity options in the module configuration page for the Inputfield or Fieldtype

@Ipa, are you wanting to be able to define something like a password policy for a site? If so, would a module be more suitable for this? Maybe Ryan could introduce a hookable "check password policy" method (if there isn't one yet) that gets called when setting/changing a password? Anyway, I'm not sure that the core is the right place to implement a password policy interface.

You might look at WillyC's htaccess rules too.

Your solution looks good, but would make the riders always appear at the bottom of the results. Maybe that's okay, but I think riders and other types of pages might be different enough that they'd warrant further segmentation or their own search, perhaps their own tabs at the top of the page, or regular pages in left column, riders in right column, etc.

You're welcome. It depends on your needs. But as written in the introduction, the easiest is to use the "Language Support Pages Names" module. The great advantage is that you have one site tree for as many languages as you need. So in your case, each page of your site is created once and then you add the content in german and english. The fact that you can also define which page is published in which language makes it even more flexible

Sorry, my mistake. I installed an adaptive images plugin on the server which is dynamically resizing images dependant on device screen size.

Yes - in the mix - Enjoy

Just checking: you've tried creating output (into a variable, such as $out = "my markup goes here") and returning that variable (return $out), not just echoing it out directly.. and it doesn't work? It definitely should, so I'm guessing there's something weird going on. If you could post some sample code that causes issues, I'd be happy to take a closer look. Answer to your non-intended question is that you'll still have to render some inputfield markup there. This is probably easiest to explain with some code. Example below will output "my value" first, then render any inputfields this wrapper contains (in this case just one markup inputfield with value "some markup.") $wrapper = new InputfieldWrapper; $wrapper->attr('value', 'my value'); $inputfield = new InputfieldMarkup; $inputfield->value = "some markup"; $wrapper->add($inputfield); echo $wrapper->render();

http://teespring.com/gulp

Hello there! Just place it into the template. If you need to run the same code on the other templates, write a function. A module would seem like an overkill here.

Nothing wrong doing that on template level.

Or you could lookup all the Saturdays in a given time-frame and build a selector from this. I don't know the inner workings of the selector engine and the queries it produces so maybe not efficient at all, but i've tested it and it seems to work. $start = new DateTime('2013-12-31'); $end = new DateTime('2015-01-01'); // grab all Saturdays between $start and $end $periodInterval = DateInterval::createFromDateString('first sat'); $periodIterator = new DatePeriod($start, $periodInterval, $end, DatePeriod::EXCLUDE_START_DATE); // build selectorValues string $selectorValues = ''; foreach ($periodIterator as $date) { $selectorValues .= $date->format('Y-m-d') . '|'; } $selectorValues = rtrim($selectorValues,'|'); // 2014-01-04|2014-01-11|2014-01-18|2014-01-25 etc. $results = $pages->find("test_date=$selectorValues"); foreach ($results as $result) { echo $result->title; }

This is one of those cases where an SQL query would be easier. WHERE DAYOFWEEK(date) = '6' But it probably isn't worth it to do an SQL query for such a simple situation, so you might be best just removing the non-Saturday dates from the results. $results = $pages->find("date>=2014-01-01, date<=2014-12-31"); foreach ($results as $result) { if (date('l', $result->date) != 'Saturday'){ $results->remove($result); } }

Thanks Ryan, I saw the release just yesterday and updated my work directory. Great job!

Logging in with email address has bee asked before (I think more than once?) and was not granted...can't find the topic now but it was mindplay. Ryan suggested to use a module instead. Mindplay ended up creating a module to do this...I'll search and post here if I find the thread..This is about ADMIN LOGIN. If you are talking frontend, please ignore me ;-) http://processwire.com/talk/topic/1838-login-using-e-mail-rather-than-username-and-general-login-issues/ Related: http://processwire.com/talk/topic/4552-user-names/ Edit: added link to thread + related stuff...

And yes yes yes! The man is cooking on gas!!!! Got it working.... well, so far. Once I finish I will bung together a quick tutorial together because this is a really complicated JQuery plugin (as far as sliders go) and it might be useful for people to know how to weld it together with PW.

Almost one year later I'm happy to say that I finally got this autocomplete feature implemented to exclude pages option. Also forced mailto links can now be disabled from module config. Version got bumped to 1.0.2. This also means that our love and relationship with PW is soon having it's first birthday. What a year! Still having butterflies in stomach.

if ($page->user->has($user)) { // Do stuff } Not tested, but something like this would work since the "user" fields returns a array which you can check all kinds of thing in. See the cheatsheet for more info.

You can't do this from the admin, as user management there is intended as an administrative task. But you can use the API to check and enforce role settings specific to your needs. For example, here's how you might make a "create vendor" form: if(!$user->hasRole('editor')) throw new WireException("You don't have access to add users"); if($input->post->submit_add_user) { $name = $sanitizer->pageName($input->post->user); $pass = $input->post->password; if(empty($name) || empty($pass)) { echo "<h3>Name and password are required</h3>"; } else if($users->get("$name")->id) { echo "<h3>That username is already taken</h3>"; } else { $u = $users->add($name); if(!$u->id) throw new WireException("error adding user"); $u->pass = $pass; $u->addRole('vendor'); $u->save(); echo "<h3>Added vendor: $u->name</h3>"; } } echo " <form action="./" method="post"> <h2>Create new user with vendor role</h2> <input type='text' name='user' /> <input type='password' name='pass' /> <input type='submit' name='submit_add_user' /> </form> ";

I and a friend used to sit in the office looking at all the book titles trying to work out difficult to guess passwords that were easy to remember. I asked my mother if she had any suggestions. She worked on the Ultra Secret during WW2 (look it up) so I was interested in her take. She made one little suggestion, so I tried it on my friend who was a bit of a hacking genius. He tried for three days and failed miserably. He gave up and said "okay, what is the password?" "There isn't one," I said. "That was her suggestion." She did the same trick with coding. She was talking to some students about how they worked with the Tipex and Engima machines and about simple codes. "Try this one," she suggested. "I like cream cakes." They battled for days trying to break it, before she gave the solution, which was "I like cream cakes." The lesson: before you waste hours trying to break a code, make sure it is actually a code in the first place! Apparently, that was a serious lesson back in the war. You had to be certain something was a code before you wasted many, many valuable hours. Joss

Ryan, Thanks this gave me a great place to start. I thought I'd share the version I created in case anyone finds it useful. • Single template for the login/logout. • Automatically redirects the user back to whatever page they originally requested after they login. ./includes/login.php <?php // Handle logouts if($input->get->logout == 1) { $session->logout(); $session->redirect($page->path); } // If they aren't logged in, then show the login form if(!$user->isLoggedin()){ // check for login before outputting markup if($input->post->user && $input->post->pass) { $user = $sanitizer->username($input->post->user); $pass = $input->post->pass; if($session->login($user, $pass)) { // login successful $session->redirect($page->path); } else { $session->login_error = 'Login Failed. Please try again, or use the forgot password link below.'; } } ?> <!DOCTYPE HTML> <html lang="en"> <head> <title>Custom PW Login</title> </head> <body> <form action='./' method='post'> <div class="login"> <? if($input->post->user && $input->post->pass) { echo "<p class='error'>" . $session->login_error . "</p>"; }?> <p><input type='text' id="user" name='user' placeholder='Username'/></p> <p><input type='password' id="pass" name='pass' placeholder="Password" /></p> <p><input type='submit' class="btn" name='submit' value='Login' /></p> </div> </form> </body> </html> <? die(); // don't go any further if not logged in } // end !logged in ?> In any template you wish to protect: <? require("./includes/login.php");?> To trigger a logout: <a href="?logout=1">Logout</a> Note: I'm using the HTML5 placeholder attribute. Browser support is not 100%. You may want to use labels instead, or use some jQuery (like I did) to add the placeholder text for browser that don't support it. SideNote: How do you get code indents to stick when posting? I'm having to go back and add spaces to each line. I use tabs when coding.

Absolutely! Here is a simple, but functional example for both login and logout templates. You would want to replace the markup with your own markup or includes. Likewise you'd want to change the redirects to redirect to whatever page you want them to go to after completing a login. /site/templates/login.php: <?php if($user->isLoggedin()) { // user is already logged in, so they don't need to be here $session->redirect("/somewhere/"); } // check for login before outputting markup if($input->post->user && $input->post->pass) { $user = $sanitizer->username($input->post->user); $pass = $input->post->pass; if($session->login($user, $pass)) { // login successful $session->redirect("/somewhere/"); } } ?> <html> <head> <title>Login</title> </head> <body> <form action='./' method='post'> <?php if($input->post->user) echo "<h2 class='error'>Login failed</h2>"; ?> <p><label>User <input type='text' name='user' /></label></p> <p><label>Password <input type='password' name='pass' /></label></p> <p><input type='submit' name='submit' value='Login' /></p> </form> </body> </html> /site/templates/logout.php: <?php $session->logout(); ?> <html> <head> <title>Logout</title> </head> <body> <h1>You have logged out</h1> </body> </html>