ryan

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?

Thanks Teppo, this is great! I'm looking forward to using this one. I did try to install but ran into some troubles. I was unable to get it to save SMTPServer or SMTPPort. I tracked that down to an issue with field dependencies (in the core, not your module). I've now fixed that in the core, but you may want to remove the requiredIf condition from those two fields if possible, at least temporarily, as I need to do more testing with the core changes I made before committing to GitHub. Once I was able to save the SMTPServer and SMTPPort settings, I tried to use the module but keep getting this message: Fatal error: Class 'Swift_Message' not found in /Volumes/RyMain/Users/ryan/htdocs/cpi/site/modules/WireMailSwiftMailer/WireMailSwiftMailer.module on line 261 It looks like this condition is failing somehow: if ($this->transport != "Smtp" || $this->SMTPServer && $this->SMTPPort && $this->senderAddress) If I remove that line above (as well as the closing brace further in the function) then I no longer get errors. Following that, I configured it for Gmail per the instructions you linked to. The instructions said to choose "SSL/TLS". I chose "TLS" first, but that didn't work. So next I tried "SSL", and that worked. So SMTP setup is now working for me and it seems to work great. Some other things to mention: 1. The module should not be autoload, if possible. WireMail is intended to be loaded on demand rather than on every request. 2. The module should not be singular, if possible. When someone makes a call to wireMail(), we want to make sure we're returning them a brand new copy rather than one that might already have some email settings populated in it. That's why singular should be false, so that every time the module is retrieved a new instance is born. 3. The module version number shouldn't have preceding zeros, as this starts PHP thinking it's an octal number or something else (I don't recall). So version number should be 6 rather than 006. 4. The require() statement in your init() function should likely be a require_once(), and it should ideally include the full path, just in case another copy of of the same directory name exists elsewhere in the PHP path. i.e. require_once(dirname(__FILE__) . '/Swift-' . self::SWIFT_VERSION . '/lib/swift_required.php');

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

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.

@cstevensjr - I grew up in McLean, VA and think I used to go to that doctor, or at least one in the same building or next door to it. It's been while, but I thought the address sounded familiar so viewed it on Google Streetview and sure enough I recognize the location. I navigated around on Streetview and see my old Starbucks, Total Beverage, McLean Racquet Club, and Giant grocery store are all still there. (I haven't been there for 10-15 years)

An HTTP hosts whitelist is important from a security aspect because http_host comes from the request rather than from the server... Meaning it can be forged. Maybe not a big deal since we always sanitize it, until you are dealing with cache, which the opens up the possibility of cache poisoning for any page that makes use of the http host. Imagine a hacker priming your cache with their own URL. Unfortunately, PHP's safe server_name variable is not reliable enough to reflect the potential diversity of http host names. So the only safe thing to do is to have a whitelist. If you aren't using the whitelist, I recommend adding it to your config.php. It's actually a little unusual for the http host to be used in PW because usually you'd just use the url() methods, which just output paths and not hosts. There's really no reason to use httpUrl() in most cases. So if you are using it, double check that you need to - it's extra unnecessary bytes unless you need to switch hostnames or schema. But with the next version of ProCache supporting multi-hosts, having an http host whitelist is now absolutely necessary.

Users still getting logged out? Just as a test, what happens if you open another window along the way, whether hitting the payment gateway URL with a target=_blank, or what not. Just curious if that keeps the session active.

Gebeer, you can ignore that guest required message. It really doesn't mean anything and I've actually got it suppressed in the latest PW. All it meant was that it was assigning the guest role at runtime, and that's something that should just happen in the background- the error message was just making confusion. As for the other issue you mentioned, the guest role is meant to collaborate with the language named "default", but it can be changed at runtime - this is exactly what the language support page names module does.

Marty, not sure why there is no sanitizer entities method there. Maybe we didn't have it in 2.2, I don't recall. Try replacing your wire/core/Sanitizer.php file with a fresh copy. It should be fine to take the one from 2.3 or 2.4. Jean-luc, glad to see you found the getForPage method. This is exactly the way that repeater pages are meant to refer to their containing page, whether in a Hanna code or elsewhere.

It should be no problem to get that setup, and we've done it many times. Take a look at the CMS case study, in the case studies board, as it describes how to do something with the same approach.

Thanks for letting me know. Looks like there was a limit set in there, and I went ahead and removed that so hopefully it works now.

Thanks for submitting your sites! We're now up to 106 sites in the sites directory. Keep them coming! I added the FieldtypeLikes module so that you can now click "like this site" for any of them (this is also used in the modules directory for the recommendations feature). I figure this will be useful for sorting and ensuring that some of the best examples of PW sites rise to the top, down the road. Perhaps we'll display the top 3 on the homepage or something. Currently "most liked" is a sort option, but default sort is by date modified. Anyway, if there are any sites you think are especially good examples in the directory, please go there and like them. The other addition is that the sites directory now uses Philipp's excellent ProcessImageMinimize module for all the screenshots.

I agree, that looks great. I'd say it's brilliant even. It's a "P" both in positive and negative space, and the whole thing is constructed from a wire. I'm wondering if the Bitnami folks would mind if we used that elsewhere.

I've posted the first iteration of the directory here: http://processwire.com/about/sites/ – I plan on doing a lot more with it (including a landing page for each site), but just wanted to get something posted quickly since we may be getting more traffic coming in soon with the Bitnami release. Thanks to those that have submitted their sites so far. Thanks especially to Marty (stillmovingdesign), one of the most prolific ProcessWire users, for taking the time to submit all of his ProcessWire sites in there. We went from having about 5 sites to having 30 after he submitted his. Now we've got about 64 sites in there. Please keep submitting posting your ProcessWire sites. We want to show a comprehensive diversity of work in the directory, and it's already coming along really well! I've added a few of your sites for testing purposes. If you already see your site there and want to change something about it, just re-submit it and I'll overwrite the existing one.

Please add your ProcessWire sites to our directory, immediately before or after posting to this board. We want to make sure that everything posted here is also posted in our official directory.

Nickie, please send me a PM indicating which product you got so that I can upgrade your access to the board. We assume that you are going to using the product key on one or more staging and development servers. We don't place limits on how many times the key can be used, other than if a product key intended for single use starts showing up on multiple production servers for different sites, then we'd inquire about it. But we all use the same key between development and production servers for an individual site, and that's encouraged.

Both guys here are correct. The session needs to be regenerated with a new session ID and some new cookies need to be set, etc. Redirecting after successful login ensures you are dealing with the new and authenticated session and $user, ready to work with.

You should be able to use has_parent=/root-parent/, replacing 'root-parent' with the name of your root parent page. That's assuming that you want to match all pages that live within the root parent and their children, etc. If you just want children of that root parent, then you'd do parent=/root-parent/

Mike, which tablet are you using again? I'm thinking it's an Android tablet, but don't recall. I've only tested on my iPhone and iPad, so probably need to expand the touch device testing into Android a bit more. We're using a separate mobile menu that's geared towards touch interfaces, but I'm guessing it's not appearing, and you are getting the desktop menu from the sounds of it.

I think Kongondo has it mostly right. But for the sake of keeping it simple, maybe ignore the part about making a copy of the AdminThemeDefault for the moment, and just make your edits to AdminThemeDefault. Once you've got them in place, you can always copy it to a different admin theme in /site/modules/ if you want to. But lets get down how to add color themes first. 1. Add your new color theme option to the AdminThemeDefault.module file like Kongondo mentioned. 2. Go into /wire/modules/AdminTheme/AdminThemeDefault/styles/sass/ and copy _vars.scss to _colors-pete.scss. The _vars.scss is based around the Warm color theme. If you prefer to use a different one as a starting point, then copy _colors-classic.scss (for example) to _colors-pete.scss instead. 3. In the same directory, edit the main.scss file and add your new colors file, making sure the others (except 'vars') are commented out: @import 'vars'; @import 'mixins'; //@import 'colors-classic'; //@import 'colors-modern'; //@import 'colors-futura'; @import 'colors-pete'; // ADD THIS LINE 4. Make edits to your _colors-pete.scss file as you see fit. You don't need to know Sass to do this, as everything is predefined with Sass variables that you can just insert new color values into it. However, read the following steps first, as you may want to setup your Sass watch to keep an eye on the changes for you as you go, so that you can see them take place in your browser as you make them. 5. Compile the styles/sass/main.scss file to styles/main-pete.css using whatever method you prefer. The standard method would be to use Sass watch. If you were currently in your styles/ directory, you could type this at the command line to automatically compile changes to main-pete.css. sass --watch sass/main.scss:main-pete.css This will keep running indefinitely, monitoring for changes and compiling them to main-pete.css every time a change is made to any one of the scss files. If you only wanted it to run once, then you'd just omit the "--watch" part. 6. Before or while you are making changes to your _colors-pete.scss file, go ahead and login to PW admin and go to Modules > Core > Default Admin Theme. Click "Settings" and change the color theme to "Pete", so that you can see your changes as you go.

@obrian7's issue report confirmed here and now fixed on dev.

Most fields require you to save their settings before they are committed. But the defaults should usually represent the unsaved state. In this case, we should probably make the default precision 0 since that's what it would be if the field hadn't yet been saved. Either that, or we should just not support a 0 precision (as there's probably no point in it for a float) and assume that to be some other default value like 2. I'll try to duplicate here, and if I can I'll adjust this behavior. Thanks for reporting it.

Avoid using dependencies in repeaters, as support is limited at present. I hadn't intended to implement them at all, and haven't written any code to support them as yet. Another user submitted a pull request to add basic support, but I think that only works with the equals "=" operator at present. If it proves to be reliable with that one operator, we will work to expand on that PR to add support for other operators.

@pers0n: go back to the first page in this thread. Events are not the purpose of this fieldtype. Events are just used as an example. The purpose of this fieldtype is for you to modify it specific to the data you need to represent, whether a table of inventory, prices, people, or any kind of tabular data you want. Even if you actually wanted to use it for events, you'd still want to modify it for the type of events given that it's not that useful in it's demonstration state. This fieldtype is meant to be changed by you.

rsync can also be used with the --delete option, which will synchronize deletions as well. rsync --archive --rsh=/usr/bin/ssh --verbose --delete account@domain.com:www/site/assets/files/* /path/to/domain.com/site/assets/files/