teppo

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

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!