Leaderboard

Wire Mail SMTP An extension to the (new) WireMail base class that uses SMTP-transport This module integrates EmailMessage, SMTP and SASL php-libraries from Manuel Lemos into ProcessWire. I use this continously evolved libraries for about 10 years now and there was never a reason or occasion not to do so. I use it nearly every day in my office for automated composing and sending personalized messages with attachments, requests for Disposition Notifications, etc. Also I have used it for sending personalized Bulkmails many times. The WireMailSmtp module extends the new email-related WireMail base class introduced in ProcessWire 2.4.1 (while this writing, the dev-branch only). Here are Ryans announcement. Current Version 0.8.0 (from 2024-09-25 -- initial version 0.0.1 was pushed on 2014-03-01) Changelog: https://github.com/horst-n/WireMailSmtp/blob/master/CHANGELOG.md Downlod: get it from the Modules Directory || fetch it from Github || or use the module-installer in PWs admin site modules panel with its class name "WireMailSmtp". Install and Configure Download the module into your site/modules/ directory and install it. In the config page you fill in settings for the SMTP server and optionaly the (default) sender, like email address, name and signature. You can test the smtp settings directly there. If it says "SUCCESS! SMTP settings appear to work correctly." you are ready to start using it in templates, modules or bootstrap scripts. Usage Examples The simplest way to use it: $numSent = wireMail($to, $from, $subject, $textBody); $numSent = wireMail($to, '', $subject, $textBody); // or with a default sender emailaddress on config page This will send a plain text message to each recipient. You may also use the object oriented style: $mail = wireMail(); // calling an empty wireMail() returns a wireMail object $mail->to($toEmail, $toName); $mail->from = $yourEmailaddress; // if you don't have set a default sender in config // or if you want to override that $mail->subject($subject); $mail->body($textBody); $numSent = $mail->send(); Or chained, like everywhere in ProcessWire: $mail = wireMail(); $numSent = $mail->to($toEmail)->subject($subject)->body($textBody)->send(); Additionaly to the basics there are more options available with WireMailSmtp. The main difference compared to the WireMail BaseClass is the sendSingle option. With it you can set only one To-Recipient but additional CC-Recipients. $mail = wireMail(); $mail->sendSingle(true)->to($toEmail, $toName)->cc(array('person1@example.com', 'person2@example.com', 'person3@example.com')); $numSent = $mail->subject($subject)->body($textBody)->send(); The same as function call with options array: $options = array( 'sendSingle' => true, 'cc' => array('person1@example.com', 'person2@example.com', 'person3@example.com') ); $numSent = wireMail($to, '', $subject, $textBody, $options); There are methods to your disposal to check if you have the right WireMail-Class and if the SMTP-settings are working: $mail = wireMail(); if($mail->className != 'WireMailSmtp') { // Uups, wrong WireMail-Class: do something to inform the user and quit echo "<p>Couldn't get the right WireMail-Module (WireMailSmtp). found: {$mail->className}</p>"; return; } if(!$mail->testConnection()) { // Connection not working: echo "<p>Couldn't connect to the SMTP server. Please check the {$mail->className} modules config settings!</p>"; return; } A MORE ADVANCED DEBUG METHOD! You can add some debug code into a template file and call a page with it: $to = array('me@example.com'); $subject = 'Wiremail-SMTP Test ' . date('H:i:s') . ' äöü ÄÖÜ ß'; $mail = wireMail(); if($mail->className != 'WireMailSmtp') { echo "<p>Couldn't get the right WireMail-Module (WireMailSmtp). found: {$mail->className}</p>"; } else { $mail->from = '--INSERT YOUR SENDER ADDRESS HERE --'; // <--- !!!! $mail->to($to); $mail->subject($subject); $mail->sendSingle(true); $mail->body("Titel\n\ntext text TEXT text text\n"); $mail->bodyHTML("<h1>Titel</h1><p>text text <strong>TEXT</strong> text text</p>"); $dump = $mail->debugSend(1); } So, in short, instead of using $mail->send(), use $mail->debugSend(1) to get output on a frontend testpage. The output is PRE formatted and contains the areas: SETTINGS, RESULT, ERRORS and a complete debuglog of the server connection, like this one: Following are a ... List of all options and features testConnection () - returns true on success, false on failures sendSingle ( true | false ) - default is false sendBulk ( true | false ) - default is false, Set this to true if you have lots of recipients (50+) to ($recipients) - one emailaddress or array with multiple emailaddresses cc ($recipients) - only available with mode sendSingle, one emailaddress or array with multiple emailaddresses bcc ($recipients) - one emailaddress or array with multiple emailaddresses from = 'person@example.com' - emailaddress, can be set in module config (called Sender Emailaddress) but it can be overwritten here fromName = 'Name Surname' - optional, can be set in module config (called Sender Name) but it can be overwritten here priority (3) - 1 = Highest | 2 = High | 3 = Normal | 4 = Low | 5 = Lowest dispositionNotification () or notification () - request a Disposition Notification subject ($subject) - subject of the message body ($textBody) - use this one alone to create and send plainText emailmessages bodyHTML ($htmlBody) - use this to create a Multipart Alternative Emailmessage (containing a HTML-Part and a Plaintext-Part as fallback) addSignature ( true | false ) - the default-behave is selectable in config screen, this can be overridden here (only available if a signature is defined in the config screen) attachment ($filename, $alternativeBasename = "") - add attachment file, optionally alternative basename send () - send the message(s) and return number of successful sent messages debugSend(1) - returns and / or outputs a (pre formatted) dump that contains the areas: SETTINGS, RESULT, ERRORS and a complete debuglog of the server connection. (See above the example code under ADVANCED DEBUG METHOD for further instructions!) getResult () - returns a dump (array) with all recipients (to, cc, bcc) and settings you have selected with the message, the message subject and body, and lists of successfull addresses and failed addresses, logActivity ($logmessage) - you may log success if you want logError ($logmessage) - you may log warnings, too. - Errors are logged automaticaly useSentLog (true | false) - intended for usage with e.g. third party newsletter modules - tells the send() method to make usage of the sentLog-methods - the following three sentLog methods are hookable, e.g. if you don't want log into files you may provide your own storage, or add additional functionality here sentLogReset () - starts a new LogSession - Best usage would be interactively once when setting up a new Newsletter sentLogGet () - is called automaticly within the send() method - returns an array containing all previously used emailaddresses sentLogAdd ($emailaddress) - is called automaticly within the send() method Changelog: https://github.com/horst-n/WireMailSmtp/blob/master/CHANGELOG.md

Lots of people have been asking for a way for ProcessWire to support sending of email, outside of just using PHP's mail() function. I haven't really wanted to expand the scope of ProcessWire that deep into email sending, but I have been wanting to setup a way so that people could override how emails are sent, with modules. For people that are interested in making other ways of sending email in ProcessWire, I've setup a new module base class called WireMail, and a new function called wireMail(). The wireMail() function will use whatever WireMail module is installed. If none is installed, then it will use PW's default WireMail implementation (based on PHP's default mail function). The wireMail() function replaces all instances of PHP's mail() function in ProcessWire's source. It works in a similar way as PHP's mail() except that supports a few different usages. Standard usage would be this: // to, from, subject, body wireMail('user@domain.com', 'ryan@runs.pw', 'Mail Subject', 'Mail Body'); Another usage would be to give it no arguments, and it'll return whatever WireMail module is installed for you to use yourself. If no WireMail module is installed, then it returns ProcessWire's WireMail. $mail = wireMail(); $mail->to('user@hi.com')->from('ryan@runs.pw'); // all calls can be chained $mail->subject('Mail Subject'); $mail->body('Mail Body'); $mail->bodyHTML('<html><body><h1>Mail Body</h1></body></html>'); $mail->send(); Since all of this stuff is only on the PW 2.4 dev branch at present, I'm posting this primarily for people that are interested in creating WireMail modules. For instance, I know that both Teppo and Horst (and perhaps others?) have put together such modules and ideas, so this is all aimed at coming up with a way for those ideas to be easily integrated into PW by way of modules. To make your own WireMail module, you simply create a module that extends WireMail and provide your own implementation for the send() method. Of course, you can go further than that, but that's all that is technically necessary. I've attached an example module called WireMailTest that demonstrates a WireMail module. When installed, it is used rather than PW's WireMail. This WireMailTest module includes lots of comments for you in the code of it, and you may find it helpful to use it as your starting point. WireMailTest.module For you guys developing modules, please throw any questions my way and I'm happy to help. Likewise, let me know if you think I'm missing anything important in the base interface that the modules are based upon and we can update it.

If you look at the database you'll see that each field is it's own database table. This is usually the first thing to freak some people out a bit when using ProcessWire (I was confused when I started!), but when you understand the power of pages (and that a couple of joins behind the scenes can often be more efficient than pulling in a massive table whether you wanted the data from every field or not) it will start to make sense. ProcessWire has been tested with at least tens of thousands of pages (and I think well over 100,000 as well) and performance doesn't seem to be a huge issue. As with any programming, as long as your selectors (PW's version of DB queries) are sensible then you should be fine. There are also a number of caching options such as MarkupCache, template caching and the ProCache module that can drastically speed up your site in a variety of ways - where appropriate. The beauty of pages is that fields can be re-used. The Body field can apply to many templates, but it's still just one table in the database. Same with any other field. You also get the ability to use Page fieldtype which let you reference other pages cleverly and which you wouldn't easily be able to do otherwise. The bottom line I guess is, there wouldn't be this number of people active in the community if it didn't work well. If it didn't work for the range of sites we've built with it, we wouldn't be using it. Yes, there is a lot to get your head around, and I found that there was a lot of baggage I'd brought from other CMS's that I had to un-learn, but once it all clicked I never looked back. Building a website in a fraction of the time I used to be able to? Yes please!

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.

Sorry about that - I did have a quick look for that, but missed it. Apparently I wasn't searching with: http://processwire.com/talk/topic/4510-field-type-json/?p=44317

Thanks, just pushed a fix for this. Good point! While I almost never use a "TO: name" (and many email clients, including gmail, don't even display it), it does make sense to support it. I've just updated it to support this. I went a little bit different route than you mentioned though, because there's always a chance two recipients might have the same name, but not likely they would have the same email. So I didn't think name would be workable as an array index. I also wanted to maintain consistency with how it's storing 'from' and 'fromName' separately, so the 'to' and 'toName' are stored in separate arrays. The 'toName' array is indexed by the email address. So now if you want to support use of 'toName' in your send() method, you'd do this: foreach($this->to as $email) { $name = $this->toName[$email]; if($name) { // send to: Name <$email> } else { // send to: $email } } If you don't need/want to support the "TO: name" (as in WireMailTest) then you don't have to do anything, as the means by which you access and iterate $this->to has not changed. As for how to supply to "TO: name" from the API side, you can do it any of these ways: // you can also use a string (or CSV string for multiple), like you would with PHP mail wireMail('User Name <user@example.com>', $from, $subject, $body); // array may be simplest if sending to multiple email addresses wireMail(array('user@example.com' => 'User Name'), $from, $subject, $body); // from the object side you can supply it as an optional 2nd argument to the to() method $mail = wireMail(); $mail->to('user@example.com', 'User Name'); // or in an array $mail->to(array('user@example.com' => 'User Name')); // or as a string (or CSV string for multiple) $mail->to('User Name <user@example.com>'); // the WireMail::from has also been updated to support a second argument or string $mail->from('sender@example.com', 'Sender Name'); $mail->from('Sender Name <sender@example.com>'); One other change is that the to() method no longer clears out any existing to() addresses on every call. So you don't have to supply all of your to: addresses in the single function call, you can call it multiple times, each with a separate email address if preferred. But if you do want to clear out the list, then just call the to() method with no arguments and it'll clear them. Yes, once we've merged the WireMail class into the master branch (stable), then I'll put out an updated FormBuilder that uses wireMail() rather than mail(). Though if anyone needs it sooner, I'll be happy to post an updated FormBuilderEmail class that uses wireMail().

But to resume all that reading "a page is not a page", it's an object within a tree structure (just as in json) with a URL (that can be available on the website or not)

it depends on what you want to do with the installation in new.mydomain.com If you drop them after successfully copied over, there is no need for transferring the DB. If you want keep the new.mydomain.com for future testings, you should not use the same DB for both. Then you should copy your DB and modify your test-domain to use that insteed. Just my thoughts,

Just sneak this old thing in: http://processwire.com/talk/topic/2296-confused-by-pages/

MVC Options: http://modules.processwire.com/modules/spex/ http://processwire.com/talk/topic/4892-an-almost-mvc-approach-to-using-templates/ http://processwire.com/talk/topic/3587-templates-mvc-recursion-etc/ http://processwire.com/talk/topic/5031-get-started-with-pw-mvc-module-by-harmster/ A few links to get you going on understanding what a page really is: http://processwire.com/talk/topic/5059-2-question-about-pages/ http://processwire.com/talk/topic/5325-database-table-versus-pages/ http://processwire.com/api/variables/pages/ http://wiki.processwire.com/index.php/Page_Field

About a month ago I announced UserGroups module, which I gave humble beginning, but Nik and Teppo really pushed forward (not sure if there is anything of my original code left anymore...). We are getting closer to initial 1.0 release feature wise, so this is good time to get more feedback from you guys. We have been focusing on finding all the different situations, where user access is defined and finding the right balance of features and simplicity. I am pretty sure there must be some cases where this module fails, so please do test all kind of combinations you can imagine and hunt some bugs! Grab the module from here and install it on big, popular and complex live site and go wild (or actually.. maybe not): https://github.com/apeisa/UserGroups/ Module is based on groups instead of roles. Idea here is that groups are something that your client can manage, but roles & permissions are not. There is no documentation or tutorial yet, but just install it - I think you will figure it soon (just create few groups, look for access tab on pages and try). Also check out this companion module that Teppo has build. It allows access management right from page tree: https://github.com/Aldone/PageListPermissions/

Words of encouragement from the Pub's amateur psychiatrist (Read best in a soft spoken, German accent) Ah, you are here because you have been reading things in this forum about pages that have left you confused, disorientated, befuddled. You thought you knew what a page was - you have been thumbing through them, folding them, studying them, wrapping things up in them and scrolling up and down them for most of your life! A page is this solid item - this great lump of data stuffed with things. But now you have come to Processwire, and everything you thought was true, simply isn't any more. For in Processwire pages are completely different - they are not great gulps of information, but tiny little things, nothing more than a link to the more interesting world of fields and templates; just a little blip of data in your huge fascinating database. Pages in Processwire are used for all kinds of things. They can be used as a marker in your pages list. They can be used as a group parent for other pages. They can be used as categories, tags or lists or users. And they can even be used for simple drop-down selects - just to supply a label and value. It can seem crazy to use such an iconic thing like a page for such a mundane and trivial task! But don't worry and fret, don't lose sleep or pace the floor as you think the reputation of the noble page is being crushed! In Processwire, they are fulfilling their duty to the full - and the more slight the task, the more they bound up to the wall and jump up and down shouting "use me, use me!" And, as a bonus, they can even be used for content - for all that stuff you thought was a page, but in Processwire isn't! So, don't be put off by the Processwire page - use it for everything! it is much smaller than you think, takes up hardly any space at all, is well behaved and only will do its thing when it is called. In fact it is hardly a page at all .... and then again, it is also so much more!! Better now? Joss Freud

http://processwire.com/talk/topic/4883-searching-pages-with-date-like-someday/ http://processwire.com/talk/topic/3290-sort-by-date-range/

Clarify... Today (your title) or certain date and time? Modified or Created? Those two are different things ...hehe...I thought Soma is on to Something!

... Attention: kongondo is on to about something ...

Maybe they're hidden or unpublished?

is a tip to start with you jooker! , drupal, what the hell is that? , something from the fifties?

Yes have read it in SwiftMailer-Thread before. I will update the module after posting this. Also have allready downloaded a fresh wire folder from Github. Lazyness! If using the object->style (not the procedural function call), there is no need to specify it when a default sender is set in config settings. But it could be overwritten by the $mail->from. Maybe I should make it an optional setting, not a required one. I have thought of a setting that prevents overwriting settings from the config screen. Default Sender is the only one valid. Recipients could be a whitelist (currently a textarea under tab advanced) and a checkbox to include emailaddresses from PW users or not. If a security restriction like this is implemented and checked, mails only get send to recipients from the valid_recipients list. Is this a useful feature? This is used when connecting to the SMTP-Server. You find it as the first entry in the Received header of every received mail. For example my local test account is called pw4.kawobi.local, this is what the headers look: Return-Path: <xxxx@xxxxxxx.xx> X-Original-To: xxxx@xxxxxxx.xx Received: from pw4.kawobi.local (dslb-084-099-066-105.t-online [84.99.66.105]) by xyz1234.smtpserver.com (Postfix) with ESMTPSA id 5EDBC2C004E6 for <xxxx@xxxxxxx.xx>; Mon, 3 Mar 2014 19:00:10 +0100 (CET) To: Peter Mueller <xxxx@xxxxxxx.xx> Subject: WireMailSmtp Test MultipartAlternative As far as I know, this is common usage, but with most clients you cannot influence the chosen name. EDIT: Module is updated to v0.0.4, look into the first post please.

U all hace too cinplicated niknames.

I have always read/typed your nick as marcura (noticed it on last reply I wrote). Now I noticed something strange on the way you typed my nick You are gonna love process modules, they are great!

Well Google does...it means you are using Drupal...hehe, just kidding . Googling that error returns Drupal stuff in the first few results... From what I see (and this is not very helpful)....something seems to be resubmitting the form? i.e. trying to create another page with the form using same name as one that already exists, or just created? (as in your step #1 in first post)....

Thanks for making this Horst! Tested here and got it working. I did have to modify your to() function (my fault, since I changed the WireMail interface for that function in the last update), but that was easy, and everything else worked (testing it with Gmail). I particularly liked being able to test the settings from the module screen. Your getModuleInfo() returns singular=true. The intention with WireMail is that it would be singular=false, so that you'd start with a new/fresh instance every time you get it from wireMail() or $modules->get('WireMailSmtp'). Otherwise, it might already have the to/from/subject/body settings from the last use still in there. Why necessary to specify the sender email address in the module settings? Will this prevent someone from being able to change the $mail->from(); address from the API side? Also was wondering why it's necessary to specify the hostname in the module settings? Does it go into an envelope from header or something?

Can you please post an updated FormBuilderEmail class that uses wireMail() sooner rather than later. Thanks.

This should get you started... http://processwire.com/talk/topic/2331-doing-additional-logic-after-saving-a-new-page/?p=21881

Thanks kongondo, sometimes it is hard for a non native speaker to bring it to the point ... I just wanted to know, if there is a way to have the checkbox for status/hidden already been checked (of course only when needed) when I start a new page. This would be fine, for I forget this once in a while. hajo

Images Manager is a fantastic and very useful module that I install on every ProcessWire site. I have a couple of sites on 2.4 and haven't experienced any problems.

To be honest, I'm not sure. Yes it's alpha/proof of concept but seems pretty stable and some use it already. But it also means it didn't get any love since then. I don't think there can happen much as it just creates pages with a image on it. So even you could go and do it without/remove ImagesManager. The parsing part for image tags could also be replaced or handled differently. It's all not things that can break easily or go competly wrong you wouldn't be able to fix somehow.

Edit....if those sub-pages will never be published, then, via their template (the sub-pages), you can remove guest role view....that way, whether published or not, guest role (the world) will never be able to view them... setup/templates/ access tab - then "do you want to manage view and edit access..." - select yes. Then, under "what role can access....", deselect guest under view pages. Save and you are done....You can always change the settings or move sub-pages that you want to be viewable to another (similar/clone) template... Above can be done in combination with limiting children of the parent whose sub-pages you want to control to only be able to use your particular template with the access controls (as explained above...) - "allowed template(s) for children" under setup/templates/ family tab... Edited: additions + clarified stuff.

In fact, here are a few posts on large-scale websites: http://processwire.com/talk/topic/4349-thousands-of-pages-one-site-with-multiple-pages-or-one-install-with-multiple-sites/?p=42909 http://processwire.com/talk/topic/1527-largest-project-performance-multi-server/

.....and a tree structure is one way of viewing it..[the object]....(it makes most sense to view in a tree...)....you can also view it in a grid/table....

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

Yes, I discovered that 2 days ago myself! Hybridauth requires the session name to be PHPSESSID to work properly. So, i changed the session name in config.php from 'wire' to 'PHPSESSID' and it started working! I'm working on integrating it with PW's users now. Will post when I have a working module ready.

.....a page is a db record ...too. Yes, you need to read up first. And, it seems you are getting confused between the page tree (just a visual representation of some db entries) and the frontend website pages (views)....Pages are infinitely scalable....Oh, btw, PW will work just fine with you storing your data NOT as pages; you just won't have access to parts of the great Page API in that case....I need some coffee, there could be mistakes

Awesome. You solved my problem, thank you.

http://processwire.com/talk/topic/5660-form-builder/

I have already integrated hybriauth, I solved the problem by commenting session_name($config->sessionName); inside /index.php. Otherwise the sessions are not recognized as equal. Unfortunately I have not developed a module, neither integrated ProcessWire's users but only session based auth.

Czech Language Pack for ProcessWire 2.4 is finished. Current version: 1.0 (99 files) + README.txt Changelog: Some minor fixes. Added last missing string All supported strings are translated. ProcessWire made hudge improvement to localization support since version 2.3. There are still some places without PW localization support (users, roles, permissions, ...) and one minor bug. I am considering this version as stable for production use. pw24_czech.zip

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.

Ryan, I would like to have the possibility not to use only the Emailaddress but also the Recipients Names with the TO-array. Actually it accepts only a single emailaddress or an array with emailaddresses, but no names. When building that on my own I would have to break compatibility. Don't like that. Could we not use something like: public function to($email) { if(!is_array($email)) $email = explode(',', $email); $this->mail['to'] = array(); // clear // check for key-value pairs containing name=>email if(array_keys($email) !== range(0, count($email) - 1)) { foreach($email as $n=>$e) { $this->mail['to'][$n] = $this->sanitizeEmail($e); } } else { foreach($email as $e) { $this->mail['to'][] = $this->sanitizeEmail($e); } } return $this; } // also within the send() function we have to check if we have array with name=>email or string only with email I'm not happy with my code example. A better way is much appreciated, but I really would like to have that possibility. ---------------------------------------------------------- - EDIT ---------------------------------------------------------- Now after some testing I came up with this code what seems to be better: public function to($email) { if(!is_array($email)) $email = explode(',', $email); $this->mail['to'] = array(); // clear foreach($email as $n=>$e) { // check for associative key-value pairs containing name=>email if(is_string($n)) { $this->mail[$type][$this->sanitizeHeader($n)] = $this->sanitizeEmail($e); } else { $this->mail['to'][] = $this->sanitizeEmail($e); } } return $this; } And in the send() function we need to loop like this: $numSent = 0; foreach($this->to as $n=>$to) { $to = !is_string($n) ? $to : ( $n . ' <' . $to . '>' ); if(mail($to, $this->subject, $body, $header, $param)) $numSent++; }

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

Hi, Does this answer on stackoverflow solve your issue? I guess it should: http://stackoverflow.com/questions/18677244/error-invalid-client-no-application-name Cheers

I'm having a difficult time imagining a scenario where templates/pages wouldn't be flexible enough to accommodate anything. It's really a matter of the logic in your templates. You can setup your templates to be as DRY as you like. There's no need to duplicate markup. Take a look at the delegate approach kongondo linked above. You may also want to check Ryan's blog profile for some ideas. There is also this discussion that may be of interest. When I first starting using ProcessWire it did take a bit to get used to the idea that there is no set way to do things. I think you'll find it's incredibly flexible, and can accommodate almost any approach. Oh, and the community here is exceptionally friendly and generous.

Hi and welcome Its easier to sort of go through this in a very boring way ProcessWire has a fairly basic construction: Fields > Templates > Pages As you would have already noticed. Firstly, it is important to realise that Templates and Template Files are not the same thing. Templates are your way of grouping fields together and template files are for markup for displaying pages. PW has no practical limits for the amount of fields, templates, template files and pages you create, so really you can do as many variations as you need - it really wont matter. The API in ProcessWire allows you to manipulate the field data associated with either the page you are currently viewing ( so $page->title, for instance) or it allows you to get or find fields from other pages or groups of pages. One of the most important areas for you to look at in the API is probably the section on selectors as this will give you a lot of details about relationships and retrieving field data. So, looking at Profiles for the moment. You might create a file in sites > templates called profile.php Then in the backend, you would create a new template - it will show that profile.php is available as a template file and you would choose that, obviously, then give your template a name - profile would be good! You now create a bunch of fields that you want to use for the profile. In some ways this is a bad example because there is already a template in the system for users, but we will pretend for the moment there isn't! However, when you create a template in the backend, after you create it you can associate other template files with it, should you wish. Add your fields to the profile template and you are half way there. From this point on, it is simply a case of using PHP and the API in profile.php to create what you need - and it is much simpler than starting from scratch. The API is very powerful and will do a lot of the work for you, while leaving you to do whatever layout you wish. That template and template file combination can now be used for creating thousands of profiles. When you link to one of those profiles, it will use the template and associated template file to render the data. The template file can be used for both displaying data and for creating input forms for editing data. (Other people can give you more of a lead about that). Now, with other pages, if you need to create completely different templates for each page because they are all completely different, then that is what you do. Not a problem. Though remember that any field can be used in any template. So, if all your templates need Title, page_meta, mani_text and so on, then you can reuse field as you wish (note, you can only have one instance of each field in a template, for obvious reasons - so if you need two textareas, you will need to create two textarea fields) The point with PW is that apart from following the relationship between fields > templates > pages, it is flexible enough for you to work however you wish, more or less and very fast once you get the hang of it.

Take a tip from the PW tutorial I am currently writing: Make a coffee, get a huge piece of paper, a pencil and an eraser, lie on the floor and get planning. You will get your approach worked out ten times as fast as you will on some new-fangled computer gizmo!

Okay, About time I put the lyrics down - you have to appreciate that I ad-libbed the entire thing at the time, playing the piano at the same time. Now are you wired? Soma's got the code, gonna make it right He's gonna program all damn night Diogo's got php on his mind Got stuck in a loop, he's in a bit of a bind Pete keeps panicking! His forum just broke He hopes all the others Just think its a joke They're all at Processwire They're living the Processwire Dream I've got it wired Processwire... Ryan is watching He knows that its true ProcessWire can kill the blues Its so real, it feels good! Processwire underneath the hood...

I tried the solfe this problem by myself and it works for me. Maybe i forgot something but Im sure that this is an nice and useful little update for your module. so I changed two files /site/modules/FieldtypeCropImage/InputfieldCropImage/InputfieldCropImage.js $(document).ready(function() { $("a.crop").live("hover", function(e) { if( e.type === 'mouseover' || e.type === 'mouseenter') { url = $(this).data('thumburl') + "?timestamp=" + new Date().getTime(); $(this).append("<img style='position: absolute; z-index: 999;' src="+url+" />"); } else { $(this).find("img").remove(); } }); // Grid Configurations function setGridMode($parent) { $parent.find("i.fa-th").replaceWith($("<i class='fa fa-list'></i>")); $parent.find(".InputfieldFileLink").each(function() { var $a = $(this); var $img = $a.children("img"); $a.css('background', '#000 url(' + $img.attr('src') + ') center center no-repeat'); if($img.width() > 99 && $img.height() > 99) $a.css('background-size', 'cover'); }); $parent.addClass('InputfieldImageGrid'); } function unsetGridMode($parent) { $parent.removeClass('InputfieldImageGrid'); $parent.find(".InputfieldFileLink").css('background', 'none'); $parent.find("i.fa-list").replaceWith($("<i class='fa fa-th'></i>")); } var $listToggle = $("<a class='InputfieldImageListToggle HideIfSingle HideIfEmpty' href='#'></a>") .append("<i class='fa fa-th'></i>"); $(".InputfieldCropImage .InputfieldHeader").append($listToggle); $(document).on('click', '.InputfieldImageListToggle', function() { var $parent = $(this).parents(".InputfieldCropImage"); if($parent.hasClass('InputfieldImageGrid')) unsetGridMode($parent); else setGridMode($parent); return false; }); $(".InputfieldCropImage").find(".InputfieldImageDefaultGrid").each(function() { setGridMode($(this).parents(".InputfieldCropImage")); }); $(".InputfieldCropImage .InputfieldFileList").live('AjaxUploadDone', function() { $("a.InputfieldFileLink", $(this)).fancybox(); // NEW Check for default Settings for Image View var $parent = $(this).parents('.InputfieldGridImage'); if($parent.is(".InputfieldImageGrid")) setGridMode($parent); }); }); and /site/modules/FieldtypeCropImage/InputfieldCropImage/InputfieldCropImage.css .crops { border-top: 0; overflow: hidden; padding: 1em; margin-right: 5px; } .crops p { margin: 0 0 0.5em 0; } .crops a { display: block; float: left; margin-right: 10px; } .crops a img { background: white; margin: 0; padding: 10px; box-shadow: 2px 2px 5px #333; max-width: 100%; } .InputfieldCropImage .InputfieldFileData { margin-bottom: 0; } /** * Grid mode icon fixes * */ .InputfieldCropImage .InputfieldHeader .InputfieldImageListToggle { float: right; padding-right: 1em; position: relative; } .InputfieldStateCollapsed .InputfieldHeader .InputfieldImageListToggle { display: none; }

Some new $options have been added to MarkupGoogleMap: 'icon' => 'http://domain.com/path/to/icon.png', Full URL to icon file to use for markers. Blank=use default Google marker icon. 'useHoverBox' => false Use hover box? When true, shows a tooltip-type box when you hover the marker, that is populated with the markerTitleField. This is often more useful than the default presentation google maps uses. 'hoverBoxMarkup' => "<div> (see below) </div>" When useHoverBox is true, you can specify the markup used for it. Use the following (which is the default) as your starting point: <div data-top='-10' <!-- offset from top of marker (in pixels) --> data-left='15' <!-- offset from left of marker (in pixels) --> style=' <!-- inline styles, or specify your own class attribute --> background: #000; color: #fff; padding: 0.25em 0.5em; border-radius: 3px; '> </div>

I've just pushed some fairly major updates to this module for version 2.0.0: Add zoom to the data managed by this module. It can be accessed from your field in the same way as address, lat and lng, i.e. $page->map->zoom. It will remember your zoom level setting from the page editor, and it can be used for generating your own maps. The map settings are now configurable in the field settings (input tab). This includes the starting/default location for the map, map height, default zoom level and map type. Removed some annoying behaviors from the geocoder. The client-side (javascript) and server-side geocoders no longer try to complete with each other. InputfieldMapMarker is now responsive so that it's input organization is just as usable at mobile resolution. Addition of a new related Markup module: MarkupGoogleMap. This provides an easy way for you to generate maps with the data managed by FieldtypeMapMarker: $map = $modules->get('MarkupGoogleMap'); // output a map with one marker echo $map->render($page, 'map'); // or output a map with a bunch of markers: $items = $pages->find("template=something"); echo $map-render($items, 'map'); This is just a basic usage example. For all options see the README.

Thanks for your updates. This module has been updated with your changes, so it now supports drag-n-drop positioning. While I was in there, I added reverse geocoding (generating an address from the marker position), live geocoding of the address changes (previously it required a submit) and a toggle checkbox to enable/disable geocoding.

slightly ot but whenever i get a chance i like to hotlink this xkcd classic