teppo

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.

Site looks wonderful and responsiveness fits the design perfectly. Great job!

I agree that it's a bit strange for filesizeStr() to always return value in kB. Haven't used it though, so it didn't bother me before Generally speaking your method seems fine, there are just couple of minor things that caught my eye: Those 's could cause a problem if used outside of HTML context. They're also not being used consistently ("0 Bytes"). It seems a bit strange that it returns "Bytes" instead of "B". All other formats are abbreviations, why not this one? Abbreviation for kilobyte should IMHO be kB, not KB. I've been using a slightly modified version of what you can find here for file-related stuff and that seems to work nicely too.

@Peter: you might want to check discussion about this in another thread (linked by Pete earlier), starting from here: http://processwire.com/talk/topic/992-problem-with-assetsfiles-folder/?p=14452. A bit further down that thread there's a post from Ryan where he explains why file directories behave like they do.

Problem here is that in order to add pages, user needs to be able to edit them too. One way to circumvent this would be a module that hooks to page::editable, checks if user has some predefined role you want to limit edit access for and (if that role is found) only grants edit access if this page was created by current user. There are other ways too, but this is probably the one I'd suggest looking into. A very similar solution is described (in more detail) by Ryan here. Hope this helps a bit.

This is pretty much explained above the config option: "Must be retained if you migrate your site from one server to another". Don't touch it and you should be just fine

@Sevarf2: thanks -- pager problem is now fixed, just pushed version 1.0.2 to GitHub

Validation tools are best used to check for real, structural problems; things that can cause you awful lot of headache when something odd happens in browser X because you forgot to close a tag or some script completely fails to function (or affects more stuff than it should) because your "unique" ID attribute wasn't unique after all. It may have been WordPress that made "code is poetry" a relatively well-known metaphor, but there's still some sense in it; working with pretty and compact (yet expressive!) code and valid, semantic markup is almost like reading a good book. Still the reality is that most people browsing your site couldn't care less whether or not it's "valid (X)HTML", so you really shouldn't sweat it too much either. (Not to mention that if you use editors like TinyMCE and CKEditor, implement any external widgets etc. you're probably going to end up with validation errors anyway.) The point I'm trying to make here is that if it makes you happy then by all means make your markup 100% valid -- otherwise just make sure that there's nothing fatal within those minor errors Regardless of that, adding empty image "alt" attribute is a good habit -- partly because it keeps validator quiet and makes spotting real problems easier but more importantly because it's actually an indicator for screen readers that "this image is not important and should be skipped." If I remember correctly, some screen readers spit out file names whenever alt is left out and that's not very cool or useful. (Will have to do some fact-checking about this later..) On the other hand, using alt texts purely for SEO is an awful idea. Seriously. I'm pretty sure that most people browsing with a screen reader don't appreciate having to listen useless, keyword-infested alt texts unless those also provide some real value for them. Sorry for taking this even more off-topic, but the subject was too fun to skip. @Joss: the site is very nice too!

As far as I'm aware (and since I'm not a lawyer or expert on this subject this may be completely wrong) Finnish law generally considers the fact that user hasn't turned cookies off via browser settings an "OK" for a site to use them. It's still strongly recommended for sites to give visitors information about how and what for cookies are used AND only use them when necessary. Haven't heard of any court decisions about this yet, though.. @extreme84: wire cookie is used to identify each section, in case that something session-specific should be stored. As far as I know, this is also required in order to find out if user has already logged in, which pretty much makes it a necessity. If there's currently an option to stop PW from setting up sessions for guests / non-admin URLs, I'm not aware of it. Minor technical note: session cookies can actually be toggled off via PHP settings, but that's generally not recommended as it would cause PHP to send session ID's as GET params (not sure if POST is also possible, but that wouldn't really change much here) which would in turn result in various security risks, so.. don't do it

Technically speaking calls to /site/ aren't a necessity and that path can even be re-configured to something else by altering $siteDir (/index.php) or default site dir in multi-domain configuration (after moving /wire/index.config.php to /index.config.php.) Admittedly this is quite unlikely.. Another thing to check would be a cookie called "wire", but that can be changed too, so it's not a flawless method either. Overall I don't think there's anything you can use to say for 100% sure if a site is running ProcessWire. On the other hand, the fact that ProcessWire can conceal it's identity pretty well is (in my opinion) a strength; not everyone wants to let general public know which CMS they're using, for various reasons.

Not sure what could be causing this, but judging from that error it would seem that either one of your tables has ascii_general_ci collation. It could also be just one column, which is also possible with MySQL.. or it could be a result of a query forcing a collation, which would seem quite unlikely in PW. Anyway, I'd start by checking if there's anything odd with the query it's trying to do, something related to pages->find() within /fr-fr/rapport_... etc. Could something on your site be sending non-UTF-8 characters to database or..?

Thanks for this, Joss. It's nice to have not only PW but also PHP tutorials here It should probably also be noted that an alternative method for handling CSV strings (which your list there seems to be, though admittedly a very simple one) is to use str_getcsv, which is available since PHP 5.3.0. In the context of your sample code it would look like this: <?php $cars = explode("\n", $page->my_textarea); foreach($cars as $car) { $car = str_getcsv($car); echo "<h3>{$car[0]}</h3>"; echo "<p>Car Model: {$car[1]}</p>"; echo "<p>Car Colour: {$car[2]}</p>"; echo "<hr>"; } There's not much difference between these two methods really, as far as I know even performance-wise they are pretty much equal. Still if there's even a small possibility that you'd need to handle more complex CSV content at some point, using str_getcsv makes sense -- that way you won't need to worry about things like commas inside quotes, escaped characters etc.

True. Should've added that within this context you should actually put a page with same name as said template to first level of your tree to avoid situation you've described above; ie. if you're having home template function as a controller this way, you should actually redirect users to /home/ and make that page your new home page. This, of course, feels a bit hackish since root page ("/") would still be there, though not in use. Wouldn't be the first time this is done, though, so I wouldn't worry about that too much.. and if it's a huge problem, you could always make your root URL behave as index action of index controller with no other actions -- or something like that. Anyway, let's make it clear right here and now that I'm definitely not suggesting anyone should try follow the steps I've mentioned here -- at least not without a very good reason, in which case slight hackishness should be tolerable. Just going with the flow here and throwing ideas around