teppo

I've got this feeling that hooks debug section is going to be my new best friend. That information could have prevented couple of very nasty situations already. Glad to have it here now, awesome stuff Ryan!

Use double quotes: $tag="1009"; // quotes are not required here by the way, using them just means that you'll get string "1009" instead of integer 1009.. doesn't really matter in this context though so use whichever you prefer foreach ($page->find("template=placemarks, tag=$tag") as $child){

Regarding moving assets (as in static site files, JS and images etc.) outside /site/: Keeping everything "site-specific" within /site/ can make upgrading ProcessWire slightly easier and enables you to move all site-specific files to another server / PW installation etc. without needing to wonder which files were / are part of PW and which belong to this specific site. This is also how (and why) modules such as Site Profile Exporter work; they simply copy (most) content of /site/ folder and leave everything else intact. So, short answer is "yes, you can do it." But that doesn't necessarily mean that you should do it

Great answers, folks! One thing to add for anyone wanting to learn responsive design is to take a good look at Responsive Web Design by Ethan Marcotte -- guy who coined term "responsive web design" and wrote that wonderful article at ALA @kongondo linked above. Book itself is ~150 pages of easy-to-read (and easy-to-understand) practical tips, explanations and examples. Highly recommended (especially, but not limited to, for beginners) and well worth those couple of bucks it'll cost you. You can't get closer to "the source" than this. Keep in mind that even if you're going to let a framework do all the "heavy" lifting for you, it's still worthwhile to understand what's actually happening behind the scenes. (Oh, and while I'm at it, I'd go as far as recommend getting that Responsive Web Design + Mobile First book bundle A Book Apart is offering. Mobile First is another book you'll definitely want to read at some point!)

Agreed. This is something I thought of too.. right after posting that original topic I haven't really had the need to switch mailer "on the fly" before (especially when using Swift Mailer, which has always been pretty damn effective at sending to multiple recipients / batch sending emails etc. out of the box) which is also why I considered replace best method here. This way once an alternative mailer module is installed and configured it just magically takes over and developer doesn't even need to know that anything has changed (other than the fact that suddenly Mailer has awesome super powers.) On the other hand, I could imagine that in some cases (such as when sending those newsletters..) one might definitely want to switch to another provider -- perhaps even a web service like Mailchimp or Campaign Monitor. For this reason alone it would make a lot of sense to have Mailer configurable at code level. There would still be multiple ways to approach this need and I don't think any of them would need to eliminate the ability to create those "drop-in replacement modules": // like posted above ... $postmark = $modules->get("MailerPostmark"); $mailer->provider = $postmark; $mailer->send(...); // ... or you could also init another Mailer! $myMailer = new Mailer("MailerPostmark");

Perhaps http://modules.processwire.com/modules/maintenance-mode/ would help here? Not 100% sure if it'll still work with PW 2.3 though, but might be worth trying

I've been using this module to fill in a database of movies lately. Lets just say that there are "quite a few" of them and it's a lot of work. My point here is that since I happened to need a few custom fields that were always there, I modified module source just enough to include those -- no need for a generic option, just couple of lines of PHP and voilà: inserting movies just got a lot easier! I'm sure this is not what you were looking for there, just wanted to point out that modifying code of this module like that is quite easy to do and can save a lot of time if you're facing importing a lot of data by hand. That's one benefit of free software / open source, you know..

So, I've been seeing some email-related topics around here and actually had quite a few struggles of my own with this very subject myself lately. Thing is that sending email should be easy, but it's not always that; especially for those who have to work on multiple, low-price (and regrettably often low-quality) platforms that may or may not provide proper mail servers.. or prefer to host their services themselves and still want to avoid setting up and maintaining a mail server. Hosting a mail server can be real pain in the ass when things don't work like they should, not to mention that most people have very little knowledge about DNS entries etc. this requires. Anyway, long story short: yesterday I started thinking that wouldn't it be sweet to have a layer of abstraction within ProcessWire for sending email? Of course one could still use PHP mail() -- there's no way and no sense in even trying to stop that -- but using a common gateway would definitely bring in some extra value. This layer I'm talking about could by default use built-in PHP mail() but also make it possible to override it, thus allowing multitude of options that PHP mail(), being bound to Sendmail / it's alternatives, can't offer without additional server-side software (such as Nullmailer.) By making sending emails hookable it could also enable all kinds of interesting tricks to be done when mail is sent -- such as writing a custom log file, sending another email to someone else, updating local content (I'd imagine that this could be useful for building newsletter platform, for an example) and so on. Since words tend to fail me at times like these, I put together a quick proof of concept of what I'm talking about here, accompanied by one example of what could be achieved by doing this: A very simple yet functional Mailer class Two commits on top here list all the changes I've made in my PW fork to make this work -- including the fact that I've altered some default modules to use $mailer->send() instead of mail() SwiftMailer module, again very simple but fully functional (though only tested with Gmail SMTP) drop-in replacement for PHP mail() So, what do you folks think of this? Please keep in mind that this is just a suggestion and I'm not saying that this is the right path to take especially considering that it would add another API variable -- it just felt like best option here and I couldn't think of cleaner way to achieve it.

Umm.. perhaps something as simple as this would work (writing from memory and not tested at all.. and I do have to admit that I wasn't 100% sure which values you actually wanted to find): SELECT t1.g_id, t1.g_title, t1.g_summary, t1.g_description FROM g2_Item t1, g2_CustomFieldMap t2 WHERE t1.g_id = t2.g_itemId AND t1.g_canContainChildren=1 AND (t2.g_field IS NULL OR t2.g_value IS NULL); Slightly offtopic: I find this representation of different join types (even if it's not entirely correct) very useful when trying to get those right..

Actually, there's one huge problem with my approach, which I only just realized (writing things up somewhere tends to help thinking process, should do that more often.) In this case I need to know what that password is in order to use it for authentication with external service. Problem is that this pretty much forces me to write it somewhere in plain text or ask it every time connections to said service are made. Unless I'm missing something important here, that is. So essentially module config storing password in plain text isn't really the problem here -- storing it securely but still using it this way is. Ideas, anyone? How do you usually solve this kind of problem.. or do you just avoid it? Edit: taking a quick look at some related questions at Stack Overflow, I'm starting to think that encrypting the passwords stored in database and storing key either within module code or (probably as an alternative option) in a file within module directory might provide slightly improved security. Still the real problem is that password is even required here.. and sadly that's something I have absolutely no way to bypass.

Altering admin template would probably be fine if I planned this module only for my own use, but since that's not the case here it simply doesn't feel right I'll probably take the custom page route here. Doesn't feel right and requires reinventing some things that default module config has already solved, but I don't really see any other options.

Thanks, @Soma. You're probably right here (as always.) Still having to create a special configuration page just because one module setting happens to be a password seems more than a bit awkward. I don't really see the connection between JSON and plain text; there's nothing wrong with storing a hash within JSON and I'm sure it could be done without clashing with "real" values -- especially considering that certain names are already "reserved" (anything starting with "_" won't get saved.)

I'm having problems with password inputs within module config: First of all, it seems that simply inserting a Password inputfield and storing it's data isn't enough; everything seems to work fine, but password gets stored as plain text, which is obviously not a good idea. I could of course apply some custom logic here, but IMHO that shouldn't really be necessary (and it would most likely just create new security problems in the long run); am I missing something or is this a real problem? Another thing is that within module config password input get saved each time module settings are saved, which doesn't seem like correct behavior; shouldn't these only get saved when value has changed? Current behavior forces user to re-insert her password each time module config is saved (this actually applies to other inputs also, though this is probably the only situation where it causes problems.) I thought this latter problem could be avoided by setting password input value, but that doesn't seem to work either.. value is cleared at some later point, before input is rendered. So, what am I doing wrong here and any ideas how to fix it?

Sounds rather odd. Taking a look at /wire/core/ProcessWire.php you should definitely see something else when debug mode is enabled -- this almost sounds like you're editing wrong site or there's something wrong with config itself (just guessing.) Any chance you could add some debug code to said file, just to make sure that it's the right place? Also: if you've set admin email in config, you should see following message: if($config && $config->adminEmail) $who .= "Administrator has been notified. "; Does that show up? Oh, and which version of PW are you running by the way?

"Create Pages" defines if users with specified role can add pages with that particular template.

This just means that everything worked as expected; Redirects module doesn't do redirect if PW page with that URL exists (it only does redirect when 404 is encountered), so when using it you shouldn't create matching page.. try removing it and redirect should work There's a slight problem in your code; it would seem that you're using (probably undefined) variable called $redirect instead of $page->redirect (redirect property of $page object, ie. the value of redirect field.) If your intention was to use value from field called "redirect", try this instead: <?php $session->redirect($page->redirect);

PHP handles closing connections automatically, so this shouldn't be a problem. According to one source this behavior could be a bit inconsistent between various PHP versions though -- which version of PHP is your host running? Depends on how they're pinging your site. Are they using HTTP or just checking if your machine replies from certain IP or..? In the former case that could affect things a bit, although it still shouldn't make much of difference. If they're checking your site every minute or something like that you could still slow it down a bit. I'm not familiar with this particular service, but they'll probably have some way to decide the time between individual pings.. and if they don't, Pingdom is a very good and very configurable alternative

@totoff: that was just the name of the variable Ryan used in his example. See how he checks and sets it in the first code block? You can store any custom variables you might need in $session and then use them on any other page for that particular (user-specific) session: $session->referrer_id = $page->id; $session->interesting_fact = "Chuck norris can slam a revolving door.";

.. or optionally this way, especially if there are more than two options: <?php if ( in_array($page->template, array('home', 'basic-page')) ) echo "something"; In your example syntax you're comparing value of $page->template (which here returns template name as a string) with regular PHP string "home|basic-page". You can't include conditional logic within strings, they're essentially just chunks of plain text

There's absolutely no technical reason behind these -- if I had to guess, I'd say that latter case just looked slightly better without the semicolon.. or it could have been simply an oversight, who knows. Personally I try to use semicolon at the end of each statement, one-liner or not, just to keep things consistent

Hi Peter, Just wanted to point out that there are couple of interesting discussions related to custom forms around; this one for an example. Essentially you'll have to create a form, by using PW elements or your own, and mostly put the logic together yourself. Depends of course a lot on what you're trying to achieve; simply sanitizing and saving user submitted content to pages (or users or..) is very simple to do via API, as you most likely already knew Lately we've been using Ryan's great Form Builder for almost all of our front-end custom forms stuff. It's super versatile and in the long run saves so much time that it's well worth the cost ($39.00 USD for one site etc.)

I'm not really sure I get what you're trying to do here and what's wrong, but isn't this essentially what you're describing there: $start = 0; $limit = 15; $values = $pages->find("parent=/, start=$start, limit=$limit") If you need total count of possible results (without limit) you could always use $pages->count() to do that separately: $total = $pages->count("parent=/"); // or like @nik pointed out below: $total = $values->getTotal();

Pageimage::url isn't hookable at the moment. If you wish, you can always make it so in your own installation by adding ___ in front of the method name, but that's not generally speaking a very good idea since running a modified version of core adds manual work to each PW update. Your best bet would be adding a new custom method / property and using that instead, like you already suggested yourself

Either that or "echo $item->widget_group_name->render()", depending on where you want to specify markup for your widgets

.. and one more take for the same subject, from slightly different angle: ProcessWire is both CMS and CMF in one package, ie. by installing ProcessWire CMF you also get "admin" which is essentially a CMS built on CMF provided by ProcessWire. The line can be a bit blurry at times Anyway, admin uses API behind the scenes, so it's not really that different from any other application you might build with PW (expect for the fact that it's probably larger.) You'll most likely want to keep it available even if you build something similar yourself -- if not for any other reason, at least to give you a nice way to view and manage templates and fields without having to do everything via API (which is of course possible too!) From my point of view there are two main ways to use ProcessWire as a platform for your applications: Bootstrapping (like Pete explained above) enables you to use it's features from strictly outside PW, ie. you could build whole application yourself and then make PW store (and fetch, sort, sanitize etc.) your data. You could also use more of the framework provided by PW by creating your application as a PW site, using template files for your application / view logic and so on. You don't really have to build modules to use PW (as a framework or a CMS) but they're a handy way to package some feature you need often into one reusable tool you can pull out whenever there's need for it. They also enable you to tweak how PW works out-of-the-box; you can, for an example, add new methods to PW objects such as Pages, without hacking core code (which is unbelievably useful at times.) Process modules (one type of modules you can create for ProcessWire) are a bit different in that they integrate directly with admin tools, providing new features there. These let you extend default admin features a lot and more often than not whatever control panel your custom application needs could also be built this way Generally speaking there are many similarities between PW and various web application frameworks like CodeIgniter and CakePHP, but PW doesn't venture quite as deep in the "generic utility" category and also forces as few restraints on you as possible. It's more focused on handling content and data types than providing you tools for general tasks (strings and numbers, email, FTP, complicated image manipulation etc.) and doesn't force a strict application structure (MVC, MTV etc.) on you (unless you build one yourself, like I've done for my own projects.) I hope this helps understand a bit what PW is, how it relates to other frameworks.. and whether it's the tool you're looking for Extra tip: cheatsheet is good place to start digging in PW. Turn on the advanced mode and you'll get pretty good idea what PW can offer.