Leaderboard

Here is slightly modified version of the slides I showed at the meetup. Lot's of interesting stuff coming soon! pw-meetup.pdf

Good meet everybody and thanks for a great company! Route where is PW going is just awesome and can't wait for all the goodies that 2014 will bring us - this thing is on fire!

To fly anywhere from Gainesville you pretty much have to go to Atlanta first. I'll grab Ryan on my way out.

https://twitter.com/foodloversdiary/status/462336755187085312

Don't think this marked solution is the solution? It's very simple. First it's always nice to know what multi-language approach you use since there's multiple ways. If you use the LanguageSupport modules with LanguageSupportPageNames also installed (which I guess you use), you'd set the language segments on the home/root page. There you'll find a name for each language. Let's assume you have german default and english alternative language, you'd probably set the name to german: "de" english: "en" This will result in urls like /de/meineseite/ and /en/mypage/ Default name could also left empty, so there won't be any language segment for it and only be /meineseite/. So, but you name them "startseite" and "home" which is strange as this would result in /startseite/meineseite/ and /home/mypage/, which is not desirable I think. So taking the language segments as described before a language switch using $page->localUrl(language) will return the correct url to the language. On the homepage this would result in domain.com (always default language, unless you set option to redirect to /de/ in LanguageSupportPageNames module) domain.com/de/ domain.com/en/ The language is always evaluated from the requested URL, and $page->url will always return urls of a page according the current language. You can get a localized url of a page explicit with $page->localUrl(language).

@owzim, just throwing in some possible reasons: Not all superusers are developers. Whether or not that's a good thing, Hanna Code allows people with no access to actual code to add features that would normally require such an access -- or at least some way to edit files on disk. It's not just about PHP code. Tiny snippets of random HTML or JS can be easily added without having to add files for those too. Hanna Code provides easy way to quickly sketch and test code snippets you're not going to need in the longer term. This is also handy when working in an environment where same site exists on multiple locations sharing database but not code (in which case moving a snippet of code in disk from one location to another would typically require extra steps). That being said, I really believe that Hanna Code would benefit from more fine-grained access management. This could mean three different permissions: hanna-code-html, hanna-code-javascript and hanna-code-php. Or perhaps just two -- hanna-code to add all sorts of snippets and another, limited permission for creating only HTML + JS snippets. The way it is right now, I can't imagine giving a client access to creating their own Hanna Code snippets, but if it allowed me to limit that access to less destructive features this module would have a lot more potential. Edit: almost forgot to mention that of course you could already add the sort of thing you're talking about, though the syntax would be slightly different (filename as a variable). GUI doesn't make that impossible and you don't really have to use it unless you want to

While testing with ImageSizer and ImagickResizer I have encountered that there are some glitches in the dimension calculations. A simple testcase I have used is to downsize an image to the half of a dimension and -1, -2, -3, +1, +2, +3 pixels. This results in 5 failures: After wrapping a ceil() here and here, there were only 2 failures and 5 succeeds: Therefor I have changed this floor to round, and this one too. This results in 7 succeeds: I send a pull request and refer to this post here, (because I do not know how to embedd images in a github pull-request or comment. --- PS: only changing the floors to rounds and not wrapping the ceils results in 5 succeeds and 2 failures

In function scope you'll have to use wire('page') or $wire->page instead of $page.

Thanks for the feedback muzzer. Good timing! As some people already noticed on twitter some hours ago, we're working on the next version of minimize.pw. https://twitter.com/minimizepw/status/462298387878907906 We've listen to all your feedback and have rewritten the whole service. It now features an async way of minimizing images that takes some more time(a minute) until changes are visible but it works much smoother without any noticable increase in loading times. We just did a live test on a site with 2000 images and around 800 visitors/day and we couldn't measure any drawbacks. Beside, the basic new features of the module will be an option to override original files and a one-click solution where we minimize every uploaded image. I've invited some people to test this and I hope we can go public around next week. We will also inform all existing customers and transfer the accounts to the new system. If you can't wait and want to beta-test, write me a message

You're welcome But I think this module is not very helpful for your task. It's mainly useful if you want to provide one corresponding PDF per page. It does also store the PDFs under /site/assets/files/ for caching purposes - not what you want actually if I understand you correctly. In your case, I guess i would be easier to use for example mpdf to create your PDFs dynamically on the fly. About security: If your booking is somehow linked to the user in ProcessWire, this could be as easy as creating a new template with a corresponding page. This template, let's call it confirmation_downloads first checks if the user is logged in, otherwise throws a 404. Then you can pass along a get parameter with the booking ID. Next, the important check would be if the user of the given ID is the user who booked. If this is the case, you could use mpdf to generate a nice PDF and directly download it. I'm planning to improve this module by switching from TCPDF to mpdf and write a wrapper class which helps to generate PDFs. I think this will be a separate module. Pages2Pdf itself then uses the new class only to generate the PDFs.

your code is kind of messed up, you can't set the variable when you're making the days array, that array has no relation to the later array $days = array(); // array for dates $events = $pages->find("template=repeater_time_loc, check_access=0"); //get all the repeaters with event information foreach ($events as $event) { $days[] = $event->getUnformatted("date"); // put event date into the array } $day = array_unique($days); // eliminate duplicate dates asort($day); foreach($day as $key => $d) { // list all the dates $today_events = $events->find("date=$d"); // find the array of events for this date and put into new array $today_events $dat = date('l, d. M Y', $d); echo "<h3>($key) = $dat</h3>"; foreach ($today_events as $doday_ev) { echo "<p><a href='{$doday_ev->getForPage()->url}'>{$doday_ev->getForPage()->title}, {$today_ev->time} Uhr</a></p>"; } }

PhotoWebMax, I think your post is very perceptive. ProcessWire appeals very much to people who are both designers and developers. It also works well for teams who divide up those responsibilities. However, it doesn't make any attempt to do development for you (like Joomla or WordPress might, for example). Having said that, what it does do is reduce the learning curve on the development side as much as is possible without sacrificing capabilities or imposing limitations on what can be done with it. I started ProcessWire as a designer too, so you're in good company. Most of my sites were not built on CMSs because I could never get the big ones (Joomla, Drupal, or WordPress) to do what I wanted, or to do it in a way that would be intuitive for my clients to manage. Anyway, the only php experience I had was using includes in my regular html sites (and whatever I could remember from the one or two non-php-based programming classes I had taken). What really drew me to PW was that I could continue making sites exactly the way that I always had-- writing all my own html, css, and choosing when and where to break up my code into external includes. And I didn't even have to learn a new syntax for that, since it was all php-based. From there, it was just a matter of learning how to grab the data from the CMS that I needed to be dynamic and putting it into my template files with the API. Going through this process opened me up to the world of development. I won't say that it was easy (or that I don't still have a lot to learn), but for me PW made programming fun and intuitive, and actually seem attainable for a design-minded person like me. And by spending time on these forums and asking a lot of questions, I was able to get up and running with the basics right away and then learn the more complex stuff from there. Now that you've described what you're trying to do with having galleries as a part of multiple templates, I do believe you have a good approach for your use case. Please don't get hung up on my way of doing things. Do what makes sense to you and will be easy for you to manage. If that means loading the scripts on all pages and sacrificing a tiny bit of page load speed, then do that. Heck, if repeating the code in every template file and not using includes at all makes it easier and gives you the more granular level of control that you need, then do that. I only looked at MODx briefly before I found PW, so I can't speak to the similarities and differences. But I will say that once I finally found PW I haven't looked back

This is what I have based my front-end logins off and all work great: https://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/?p=15919

Really? I don't think so. I think it's more meant that your video is better positioned if you use youtube to host them and embed in your site. Not that your site get's a better rank just by embedding youtube videos.

adrianmak, Welcome to the forums. Fields can have a column width assigned under "details". You can also assign a column width on a per template basis. There is a field type called "FieldsetTab" that will allow you to group fields into a new tab.

I'm jealous! Glad you guys had a nice time

I did buy this amazing Underwood in perfect condition for $50. Its nice to look at but I don't use it that much - other than writing my ransom notes of course...

@slkwrm Thanks for the hint. Actually it turns out that the repeater page's parent is not the page where the repeater field is, but this page can be got by calling the method getForPage. So the correct code is: $containerPage = $page; if ($page instanceof RepeaterPage) { $containerPage = $page->getForPage(); } // can be checked with echo $containerPage->id; I added this container page calculation at the right place (I hope!) in TextformatterHannaCode.module and the repeater field case now seems to work for hanna codes.

@jean-luk Yes repeaters are in fact internal pages, so doing the following should help (not tested): if ($page instanceof RepeaterPage) { $id = $page->parent->id; } else { $id = $page->id; } echo $id;

One thing I think is important is that all of this advanced back-office functionality needs to be modular - for most sites out there none of this is needed, but for those that benefit from this level of complex management, offering a full solution is quite a game changer. Hey, I talk to myself all the time - or is that not the same problem??

@bcartier: The ImportPagesCSV-module can't do this as is. But I tried making a tiny addition to make it support FieldtypePage (those used to make page references) and it worked amazingly well. The only change needed was to add 'FieldtypePage' to $fieldtypes array (just before init() function if you take a look at the module file), like this: protected $fieldtypes = array( 'FieldtypePageTitle', 'FieldtypeText', 'FieldtypeTextarea', 'FieldtypeInteger', 'FieldtypeFloat', 'FieldtypeEmail', 'FieldtypeURL', 'FieldtypeCheckbox', 'FieldtypeFile', 'FieldtypePage', // add this line ); After that addition it's possible to choose a Page field when connecting the fields from the CSV to the ones in the chosen template. I had pre-populated categories at the target site and used their id's in the CSV file to reference those categories. Multiple categories worked like a charm as well, just use a pipe in between id's (123|456|789). Moreover, if you've got only one category per entry to reference, then you don't even need the id's of the categories - you can use paths as well. Here's a little example: cat.csv: title one two three four entries.csv: title,categories a,/cats/four/ b,/cats/three/ c,/cats/one/ d,/cats/two/ Import cat.csv using a template for categories with (at least) title field, under a page at /cats/. Then import entries.csv using a template for entries, having a title field and a page field. This should leave you with entries that are connected to categories. I hope this gets you somewhere. @ryan: Looks like page references could be supported very easily. I just used this successfully to import ~3500 pages with category references from an old site to a new PW one. But maybe there's still something else to be done before they're fully supported?

I recently had to setup front-end system to handle logins, password resets and changing passwords, so here's about how it was done. This should be functional code, but consider it pseudocode as you may need to make minor adjustments here and there. Please let me know if anything that doesn't compile and I'll correct it here. The template approach used here is the one I most often use, which is that the templates may generate output, but not echo it. Instead, they stuff any generated output into a variable ($page->body in this case). Then the main.php template is included at the end, and it handles sending the output. This 'main' template approach is preferable to separate head/foot includes when dealing with login stuff, because we can start sessions and do redirects before any output is actually sent. For a simple example of a main template, see the end of this post. 1. In Admin > Setup > Fields, create a new text field called 'tmp_pass' and add it to the 'user' template. This will enable us to keep track of a temporary, randomly generated password for the user, when they request a password reset. 2a. Create a new template file called reset-pass.php that has the following: /site/templates/reset-pass.php $showForm = true; $email = $sanitizer->email($input->post->email); if($email) { $u = $users->get("email=$email"); if($u->id) { // generate a random, temporary password $pass = ''; $chars = 'abcdefghjkmnopqrstuvwxyz23456789'; // add more as you see fit $length = mt_rand(9,12); // password between 9 and 12 characters for($n = 0; $n < $length; $n++) $pass .= $chars[mt_rand(0, strlen($chars)-1)]; $u->of(false); $u->tmp_pass = $pass; // populate a temporary pass to their profile $u->save(); $u->of(true); $message = "Your temporary password on our web site is: $pass\n"; $message .= "Please change it after you login."; mail($u->email, "Password reset", $message, "From: noreply@{$config->httpHost}"); $page->body = "<p>An email has been dispatched to you with further instructions.</p>"; $showForm = false; } else { $page->body = "<p>Sorry, account doesn't exist or doesn't have an email.</p>"; } } if($showForm) $page->body .= " <h2>Reset your password</h2> <form action='./' method='post'> <label>E-Mail <input type='email' name='email'></label> <input type='submit'> </form> "; // include the main HTML/markup template that outputs at least $page->body in an HTML document include('./main.php'); 2b. Create a page called /reset-pass/ that uses the above template. 3a. Create a login.php template. This is identical to other examples you may have seen, but with one major difference: it supports our password reset capability, where the user may login with a temporary password, when present. When successfully logging in with tmp_pass, the real password is changed to tmp_pass. Upon any successful authentication tmp_pass is cleared out for security. /site/templates/login.php if($user->isLoggedin()) $session->redirect('/profile/'); if($input->post->username && $input->post->pass) { $username = $sanitizer->username($input->post->username); $pass = $input->post->pass; $u = $users->get($username); if($u->id && $u->tmp_pass && $u->tmp_pass === $pass) { // user logging in with tmp_pass, so change it to be their real pass $u->of(false); $u->pass = $u->tmp_pass; $u->save(); $u->of(true); } $u = $session->login($username, $pass); if($u) { // user is logged in, get rid of tmp_pass $u->of(false); $u->tmp_pass = ''; $u->save(); // now redirect to the profile edit page $session->redirect('/profile/'); } } // present the login form $headline = $input->post->username ? "Login failed" : "Please login"; $page->body = " <h2>$headline</h2> <form action='./' method='post'> <p> <label>Username <input type='text' name='username'></label> <label>Password <input type='password' name='pass'></label> </p> <input type='submit'> </form> <p><a href='/reset-pass/'>Forgot your password?</a></p> "; include("./main.php"); // main markup template 3b. Create a /login/ page that uses the above template. 4a. Build a profile editing template that at least lets them change their password (but take it further if you want): /site/templates/profile.php // if user isn't logged in, then we pretend this page doesn't exist if(!$user->isLoggedin()) throw new Wire404Exception(); // check if they submitted a password change $pass = $input->post->pass; if($pass) { if(strlen($pass) < 6) { $page->body .= "<p>New password must be 6+ characters</p>"; } else if($pass !== $input->post->pass_confirm) { $page->body .= "<p>Passwords do not match</p>"; } else { $user->of(false); $user->pass = $pass; $user->save(); $user->of(true); $page->body .= "<p>Your password has been changed.</p>"; } } // display a password change form $page->body .= " <h2>Change password</h2> <form action='./' method='post'> <p> <label>New Password <input type='password' name='pass'></label><br> <label>New Password (confirm) <input type='password' name='pass_confirm'></label> </p> <input type='submit'> </form> <p><a href='/logout/'>Logout</a></p> "; include("./main.php"); 4b. Create a page called /profile/ that uses the template above. 5. Just to be complete, make a logout.php template and create a page called /logout/ that uses it. /site/templates/logout.php if($user->isLoggedin()) $session->logout(); $session->redirect('/'); 6. The above templates include main.php at the end. This should just be an HTML document that outputs your site's markup, like a separate head.inc or foot.inc would do, except that it's all in one file and called after the output is generated, and we leave the job of sending the output to main.php. An example of the simplest possible main.php would be: /site/templates/main.php <html> <head> <title><?=$page->title?></title> </head> <body> <?=$page->body?> </body> </html>