teppo

Issue was quite obvious, actually: that "if" made sure that Swift Mailer wouldn't get initiated with SMTP transport unless it was properly configured. With the old logic this would've been fine, but not anymore, since local send() method is called regardless of whether Swift Mailer is available. Stupid mistake from me I've changed this so that if you select SMTP transport but don't fill in required params (server and port), the module will fallback to Mail. This (kind of) brings up another possible issue, though I'm not exactly sure how to deal with that yet: what to do when there's a connection issue in send()? Should that be caught and logged, should I throw an exception.. or is there even better alternative? So far I'm thinking that an exception would be best way to handle this, so that apps / sites that rely on mail getting won't just continue like nothing happened.. though that might actually cause even more confusion. Suggestions would be more than welcome

@ryan: thanks, great suggestions! I did notice the issue with saving settings, but had planned to reduce it to a proper test case and submit as an issue. Should've acted faster and disabled it right away, though, to avoid any unnecessary confusion Autoload and singular state were carried over from the original module, the intention of which was quite different from current implementation. I've taken care of these already, but will have to change the require logic you mentioned, as that admittedly no longer makes sense (and path part would've made sense even in the original form). So far I haven't been able to reproduce this. Will continue testing, though, since if it happened to you it's probably going to happen to others too. Shouldn't be too hard to figure out (*fingers crossed*). I remember having problems remembering and "getting" the version number logic originally -- 006 was probably carried over from the time I first put this module together. Lately I've used integers, as that seems to be the expected thing there. Slightly off-topic, perhaps, but integers still seem like a bad fit for version numbers to me. Version numbers should be able to go beyond 0-9 range.. and how do you represent versions such as 1.11.24 as an integer without actually using three sets of numbers? Of course there's always the option of using strings in those cases, but I find it weird that integers are seen as "the default way" while they are only capable of representing some version numbers properly

Sounds like a good way to deal with it. That way users trying to get an ID that doesn't exist would simply get your default home page. Makes sense.

Quick tip: you can also use $pages->count($yourSelector) to get the number of matching pages. That's just a shorthand though, under the hood it does exactly what @horst did earlier

PHP doesn't like Exceptions in included files and (assuming that it's prependTemplateFile) _init.php is included during page rendering. I'd suggest putting together a simple module for this. Edit: you could, probably, also do this in your home template, right? Assuming that old URL's were always "/?id=*", they should always end up on your home page and that should work just as well.. or even better?

If the error is "request header or cookie too large", it'd be helpful if you could take a look at headers and cookies sent for that request and see if there are any anomalies there. From there it would be easier to debug why that's happening

AWESOME start for each new day at the office: (Number #1 song in my "top tracks" for this week. Seriously.)

@lpa: I'm seeing this issue too, can't quite figure out what's causing it yet though. Twitter authentication should work from localhost, at least as long as callbacks etc. are set properly (quite a few topics about this if you try Googling). Twitter's oAuth test (cURL) is working from localhost, but the module doesn't. I'd check if code samples in tmhOAuthExamples work either, but don't really have the time right now.

Exactly what I've been doing too. Too lazy to go through install routine, I guess..

This may be a bit off-topic (nothing new from me), but I remember someone saying that "Page" makes much more sense than "Node" (for an example) for web use, and I really do agree with that. Still it's interesting to see how people not used to ProcessWire's jargon (and often coming from other systems and/or custom-built applications) get confused here. CMS/CMF such as ProcessWire has to manage content as nodes / items / pages / rows of some form and in this case those items are called Pages. They're not that different from Nodes in Drupal or Posts (and, these days, a whole bunch of different "post types") in WordPress.. or even from simple database rows. The main difference between database rows and Pages, of course, is that Pages have mostly web-related helpers (methods) attached to them and the built-in ability to pull content automagically from multiple tables. Sure, you could say that Pages are objects and thus have some overhead from there, and you'd be absolutely right. Then again, it all depends on your use case and what really matters for you. Most things built in ProcessWire could be considered "web sites" and web sites usually consists of (surprise!) Pages. Makes sense, huh? It is also important to note that you don't actually have to use Pages for everything. Saying "in ProcessWire everything is a Page" is misleading. It's true for the bulk of everything built with ProcessWire, but there are exceptions. For my Version Control, Changelog and Login History modules, for an example, I chose another route: a custom database table. In my opinion custom database tables are better option in some cases, but this way (like Pete already pointed out) you won't be able to use ProcessWire's selector engine; you'll have to write all your queries as plain, old SQL instead and route them through $db (MySQLi) or $database (PDO) objects. Doable, but potentially less secure (with selectors there's no risk of SQL injections, for an example) and more complicated. There's also the option of creating custom Fieldtypes. Each Fieldtype defines it's own schema, so this is very viable alternative to custom database tables. This way you'll still be able to work with native selector engine, but you'll get some of the benefits of plain database tables also. Ryan's Events Fieldtype is a good example (and starting point) of this. ProcessWire sets very few limits on the way you work. Want custom tables? Sure, go ahead, do it. Want to use Pages you can add fields to later with ease, edit with built-in admin tools and find using selectors? Sure, we can do that too. Combination of both, pages with fields of custom type and schema? No problem, we've got you covered. .. and this is one of the main reasons I love ProcessWire.

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..