teppo

FormBuilder needs to be updated to use wireMail() instead of mail() first, so not exactly out of the box, but I'm sure Ryan will take care of this

@adrian: I browsed through the plugins just today, wondering if (and how) some of those should be implemented. Not sure yet, but there's undeniably a lot of useful stuff there and it'd be shame not to put any of those in use. One could always use wireMail() to return instance of WireMailSwiftMailer and it could, in turn, return instance of SwiftMailer.. though admittedly that's not so different from instantiating it yourself

Just in case that someone happens to read this topic, introduction of WireMail base class by Ryan now makes it possible to build custom email handling modules. Swift Mailer module introduced here has also already been converted to WireMail module.

This module integrates Swift Mailer mailing library to ProcessWire, providing support for three different "transports" or methods of sending email: SMTP, Sendmail and Mail (essentially PHP's native mail() function). WireMail is email-related base class for ProcessWire. See this post by Ryan for the details. Important thing to note here is that a) it's brand new, so as of this writing you'll need a fresh dev version of ProcessWire to use this and b) it makes integrating new ways of handling email-related tasks very easy. Getting started You can download or clone the module from GitHub: https://github.com/teppokoivula/WireMailSwiftMailer/. Using this module is as simple as downloading / cloning it to your modules directory and installing it. If you're going to use SMTP or Sendmail features, insert correct SMTP credentials / Sendmail command to module settings first. Third transport, Mail, is included simply because it's a native feature of Swift Mailer; if you're going to use it, I would suggest against installing this module. ProcessWire's native WireMail implementation handles this part just fine. Basic usage Sending emails should be done using wireMail() function -- if you use mail() directly, you're going to bypass ProcessWire's email handling features entirely. Main difference between mail() and wireMail() is the order and number of arguments: $number_of_recipients = wireMail($to, $from, $subject, $body); For more information please take a look at README. This module is released under GPLv2 (just like ProcessWire itself) with the exception of included Swift Mailer library, which is copyright © Fabien Potencier and released under the MIT license.

Unless I'm somehow missing your point here, inputfield doesn't matter when working over API. Insert values and save the page, that's it: $page->of(false); $page->page_field = $pages->get('name=my-page'); $page->page_field = 1; // etc. $page->save(); For more examples take a look at this post.

I can't seem to break it anymore myself, so I've just pushed Swift Mailer module to GitHub. It's still far from complete and probably lacking lots of important stuff, but if anyone wants to give it a try already please do so.. and let me know how it went. I'll create an "official" thread when it feels slightly more polished

@ryan: just noticed that use case 3, "specify both $body and $bodyHTML as arguments, but no $options", doesn't seem to work as described. Later $options is used as an argument of array_merge(), which means that it has to be an array itself.

Got first version of SwiftMailer implementation working locally, should be able to push to GitHub after some testing. Ryan has, once again, made things too easy for us..

$config->scripts and $config->styles are FilenameArrays, so you can use following methods to remove content: $config->scripts->remove($filename); // remove one file $config->scripts->removeAll(); // remove everything

@Damienov: by documentation of specific modules, are you referring to core modules (those shipped with PW itself) or 3rd party modules (most of the stuff in modules directory)? What kind of things would you expect to find from such a documentation? Asking because I'd be more than happy to provide better docs for my own modules, but I've no idea where to start, what would be generally useful etc. I'm a "screw your docs, just give me the code" kind of guy myself

@r2d2: for quick figures you'll probably want to find existing articles and discussions from Google. ProcessWire developers are not a special group when compared to, say, Drupal developers. Except, of course, that they're using a far superior platform This little post was something of a wake-up call for me: http://speckyboy.com/2013/07/08/turn-your-web-design-agency-around-by-raising-rates/. Things like that, of course, depend entirely on what kind of projects (and clients) you're interested in, what can you do for them that's worth their money etc.

@adrian, you're on the right track there, but the point is that you can't use '%=' with id's and '=' isn't always enough for text-searches, so in order to include both queries in one selector and achieve what (I believe that) David was trying to achieve you'd have to use an either-or selector (see examples below) or combine results of two separate queries. // wrong id|name%=1001|about // correct, but *not* the same thing id=1001, name%=about // correct, but requires either-or selector (id=1001)||(name%=about) // probably correct, but requires either-or selector and makes very little sense (id=1001|about)||(name%=1001|about) Forgive me for using dummy syntax for either-or, I've no idea how Ryan is going to implement this It should also be noted that id|name%=1001|about, if it worked (or that last either-or example above), would also return pages with names like "mypage1001", which probably wasn't intended. Considering that, this is definitely a job for either-or selector (first one in example above) or two combined queries.

@adrian: http://processwire.com/talk/topic/2942-or-in-pw-selectors/?p=29001 On a mobile so I'll be very brief, but just wanted to add that the original issue is exactly what error message says: id field and %= can't be used together. You could use a combination of two finds (fetch two PageArrays and merge them) to achieve this, though someone might know better way too..

One more addition to answers above: you should take a look at Hanna Code module. It allows you to pull snippets of arbitrary PHP code into pages. This is what I've used to solve more complex needs, pages that need weird snippets etc. Typical issue with Hanna Code is that you won't be writing the code as files, so they won't be in your version control system etc. One way to solve this is to create Hanna Code snippets that include code from files and/or actually render pages. There's quite a lot that this little beauty can do, actually. Many of us "long-time PW users" have developed our own ways to work with PW. I'm using something similar to Zend Frameworks approach, with controllers, view scripts and partials, for an example. This is both a curse and a blessing with extremely flexible system like ProcessWire; you can create your own way to work with it, but especially if you're working on more complex stuff you'll also pretty much have to do that

Any chance that you've migrated this site (including users) from another server / PHP version? In any case this sounds like some sort of issue with Blowfish / PHP crypt function. One possible solution (though not one suggested in the long run, especially if this is a production site!) was provided by Ryan here. Quick Google search also returns a ton of related topics, so I'd probably start from there.

I'm in!

You could also check out UserGroups, also discussed here. As the name suggest, this module adds new concept called "groups" (ProcessWire, by default, only knows "roles") and allows you to specify page-based permissions for users belonging to these groups. Companion module PageListPermissions provides alternative, page-tree-based UI and in some ways makes things easier to manage. Word of warning, though: UserGroups isn't considered quite "production ready" yet, so tread carefully. Generally speaking it's more useful when your needs are slightly larger, i.e. you need a lot of different sections editable and/or viewable by specific groups of people. If you do try it out, any feedback is welcome

Thanks for that! I stand corrected; I did not know that requesting an absolute URI would result in Host header being ignored. That's quite interesting -- or "frightening" even, as one commenter there pointed out about the whole thing. Now the only thing I'm not getting here is that wouldn't it, in this case, make more sense to look for an absolute URI in REQUEST_URI and if found, use that instead of host header? I guess this wouldn't solve the problem for various dedicated hosting setups, though, so perhaps it's not really viable "global" solution. I guess I'm mostly annoyed about having to keep an up-to-date list of hosts in multiple places instead of letting Apache take care of that. So much potential for unexpected misconfigurations This is exactly what I don't understand -- why would I want to redirect user from HTTPS to HTTP when "view" is clicked? Not much of a problem usually, but I find it a bit strange .. and back to the original topic: Personally I still feel that this is a problem. When installed locally, PW offers "localhost" as the default httpHosts value. That's fine until you move the site to your web host and suddenly things won't work. I'm afraid that a lot of people won't really think twice about that setting or even remember it exists. Of course it might be just me who's got such a crappy memory, but I wouldn't be surprised if topics like this started popping up quite often. Not sure if there's any bulletproof solution to this, though (other than making this an optional security setting, that is -- and making security "optional" always sounds awful).

Isn't host header exactly what the server uses to decide which site, if any, to serve.. or could it be that this is specific to virtual host setups? Those have been the most efficient option for me so far, so I haven't really had to set anything else up, which could explain why I'm having trouble following you here. With that kind of setup your vhost files include all possible hosts for each site, in which case whole httpHosts whitelist seems unnecessary (and even confusing) repetition Just gave this a try on my own site by providing dummy host header (testing via telnet) and that -- as expected -- resulted in Apache default page showing up. I'm not seeing how anyone could use that for their benefit. Then again, if this isn't always the case, there definitely could be potential for abuse. Also: the problem, as explained by @gunter, is with ProcessPageEdit; it uses httpUrl for view links. That does seem a bit weird, so perhaps it's a leftover or something?

@dragan: that's good to know and definitely not nitpicking -- my intention at this point is to make this module support all native fieldtypes (except images and files, though I'll hopefully get there eventually), including checkboxes. I'm starting to realize that not writing specific tests for multilanguage part was a huge mistake, obviously there are quite a few weird things happening there As soon as I get the time, I'll write a test case for checkboxes (for starters) and see what exactly is going on. It should work.

@gunter: see if httpHosts setting is in place in your /site/config.php and contains only "localhost", that's the most likely culprit. Ryan: if you're reading this and if aforementioned really is the problem here, I'd say that this is an issue that should be dealt with.. personally I'm against this whole setting (I'm seeing more issues than benefits there), but at least it should stay out of way as far as possible -- opt-in instead of opt-out.

That sounds good and you'll definitely have more up-to-date results with that approach. I used cron mostly because sites in question were really large, content is constantly being updated and generating the JSON file could take (relatively speaking) a long time. I didn't want each page save to take that long.