Jump to content


  • Posts

  • Joined

  • Last visited

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    London, UK

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

ffub's Achievements

Jr. Member

Jr. Member (3/6)



  1. I'd definitely like to see this. I use SwiftMailer at the moment and love its object orientated approach over php's mail(). I send most of my mail through Mandrill or Mailgun. I currently use SMTP but it would be nice to have transports that send via their APIs as these offer a few more options. It would also be a really easy route for ProcessWire to receive mail in a standardised manner - you ust provide an enpoint for their webhooks and a hookable method for consuming them.
  2. Hi, thanks for the feedback. I'm going to have some time to work again on this module next week. Ryan, I think I will store the email as synched to mailchimp against the user and then use to handle email changes rather than looking up via the database directly. soma, I saw you wrote about your MailChimp module on another thread and I certainly think they could work alongside each other. I hadn't realised it was not possible to create a list via the API so I'll have to keep this as a setting. It only needs to be done once though, as my approach is to sync the user database with a single list and build on the segmenting MailChimp encourages. It may be feasible to have the same module synchronise a page array instead of just $users, which would allow people to manually add people to lists without adding them to the user database. I'm concentrating on $users for the moment though as this is the use case that best fits me.
  3. I agree about order, Steve. I think a payments abstract class should record the payment details and then orders (in a shopping setup), subscriptions, or donations can simply reference the payment with a page reference field.
  4. Hi all, I've been looking at adding MailChimp synchronisation to PW. I have a few sites with users that have to register and it's much simpler for me to have the whole user list synchronised into MailChimp rather than adding people on a case-by-case basis (as I have done in the past). With this in mind I have created a prototype module that syncs the whole list, a few fields and user roles. This allows you to send MailChimp campaigns to a segment of your users based on their roles. You can download and try out the module here: https://github.com/ffub/MailChimpSync I've a few ideas of where I want to take this: Switch to scheduled updates. To avoid updating the whole list users should be flagged as requiring an update when one of the relevant fields is updated. LazyCron or cron jobs would update flagged users. Automatic creation of the list on MailCimp and initial import. It would also be possible to add an interests field in PW and synchronise this too, which would effectively allow you to create lists in PW. I've had to hook before the user is actually saved as this is the only clean way I could find to get their new email address and their existing one at the same time. This is pretty inefficient as this holds up the user being saved in PW until the MailChimp update is done. I'd also like to only update the user when the fields defined in the module are updated, rather than the user as a whole. Stephen
  5. I've integrated both Stripe and PayPal into some PW sites and would be interested in a generalised payments setup for ProcessWire. I rather liked the way you added Payment support to your eCommerce module, apesia, but when I came to add payments for a subscription module I ended up creating parallel modules that could handle the different scenarios.
  6. Just wanted to add to this discussion that one of the clear benefits of using templating engines is being able to share templates and partials between different programming languages, and thus between client side and server side aspects of your site. This is very handy when building web apps or heavily ajax-ified sites.
  7. Great work on the new theme and upgrade. The forums are looking great.
  8. Thanks, netcarver! Sound advice and I believe you've helped me solve it. The function isn't static, no. I didn't realise that method of attaching a hook was only for static functions. I've not looked into how PW actually makes the module methods hookable but I had sort of assumed that it creates its own methods without the underscores which call the method and associated hooks. If so, I guess these are static. I have pretty rudimentary knowledge of both object orientated PHP and PW's internals though. By zero-ing on line 53 you've made me realise my error. The function was getting called but as I was calling it with the underscores it was not calling the associated hooks. I've removed the underscores and the hooks are now working. Much of the business logic you'd use to verify the payments is outside of the scope of the module as it stands, such as checking the email and postal address of the transaction against an order, or checking the orderID matches that returned by PayPal. That said, checking the transaction ID is certainly something that could be done if I expand it to keep track of all payments it receives. Any other suggestions welcome! Stephen
  9. Both modules are singular and autoload. The reason I'm autoloading the PayPal module is because it listens out for IPN responses. This could be done with a separate template that loads the module but I preferred the neatness of not having to set up any templates on install.
  10. Hi all, I'm writing a utility module to send basic payments to PayPal and then to validate the IPN response that PayPal returns. The module is a simple wrapper around their Website Payments Standard api. You can view the module here: https://gist.github.com/4493175 When you initiate a payment the customer is redirected to PayPal where they complete the transaction, and then returned to the "thank you" page as set in the module settings. PayPal sends a copy of the transaction and its status (authorised|cancelled|refund etc) to a specified listener. Once your site receives this copy, you validate its authenticity by sending it back to PayPal who confirm that they sent it to you. So far so good. The problem I am having is adding a hook to the method that processes a successful payment validation from another module. I'm trying to use this code to hook the method but having no luck: /** * Initialise the module * */ public function init() { // Add a hook after to update member role and expiry date $this->addHookAfter('PaymentGatewayPayPal::processIpn', $this, 'processPayment'); } /** * Process the successful payment * */ public function processPayment($payment) { mail($myEmailAddress, "Test payment processing", "This ran"); } Can anyone suggest where my hook might be going wrong? I'm also keen on any general tips on how the module could be made more robust before I release it. Best regards, Stephen
  11. I'm happy to write some documentation as I already have to do a little of this for my clients. Is it just a case of getting a login for the wiki until we find something more ideal?
  12. Hi this was discussed a little in another thread: http://processwire.c...age__hl__mailer I actually use templates and Mandrill to send some of my transactional emails such as welcome emails and confirmations. It's relatively easy to do this using SMTP. Here's an example: <?php require_once "Mail.php"; require_once "Mail/mime.php"; $email = new Page(); $email->template = $templates->get("email-template"); $email->somePageVariable = "example"; $email->setOutputFormatting(true); $body = $email->render(); // Header info $from = "<info@yoursite.com>"; $to = "<user@name.com>"; $subject = "Thank you for registering!"; // Send via Mandrill $host = "ssl://smtp.mandrillapp.com"; $port = "465"; $username = "info@yoursite.com"; // Your mandrill user name $password = "secretKey"; // Your mandrill API key $headers = array ( 'From' => $from, 'To' => $to, 'Subject' => $subject, ); $smtp = Mail::factory('smtp', array ( 'host' => $host, 'port' => $port, 'auth' => true, 'username' => $username, 'password' => $password )); $message = new Mail_mime(); $message->setHTMLBody($body); $mail = $smtp->send($to, $message->headers($headers), $message->get()); if (PEAR::isError($mail)) { echo($mail->getMessage() . "\n"); } else { echo("Message successfully sent!\n"); } Because the template can pull in content anywhere from your site, you can easily make templates for upcoming events, latest news, etc. For inlining CSS, premailer now offers an API. I think it's best to use netcarver's tag parser for user-specific details when bulk mailing. You could render these in the template and pass in the user ID to that, but then you'd have to inline the CSS after rendering each and every email. It should be possible to avoid this by rendering the template, sending to premailer, and then looping through the recipients replacing the first_name, surname etc. I've not tried this out yet though. Stephen
  13. Hiya, I'm using this module on a couple of sites now, but most notably on the site for my climbing club: http://nlmc.co.uk/meets/ The previous events list is getting pretty long and I was wondering how complicated it would be to add pagination? Stephen
  14. I don't think colour is any different a variation to size. The product details may well otherwise be the same, such as description, title, price so you'd have unnecessary duplication unless you created a layer above product such as product-group. I built a shop this summer using the above e-commerce modules, but significantly rewrote the checkout module to be a lot simpler. I used repeaters as variations and allowed a number of fields for each variation. If you have a tshirt design, in three different colours and three different sizes, each of those colour and size combinations will need an inventory count. As such I added two drop downs for size and colour and a field for stock to the variation template. The title and price of each variation were set using another module and a couple of property hooks. The title concatenated the titles of the product, size and colour. The price checked if the variation had a price set on it, and if not, grabbed the price from the product it was a variation of. I found this the most sane way of dealing with the variations and it allowed the cart module to be none the wiser as it simply viewed each variation as a product and when it asked, was supplied with a title, price and stock count for that variation. Stephen
  15. You're right, Pete. I think splitting this into a few modules which handle different levels of integration with those third party services would be most sensible. A basic email templating module that adds support for creating HTML emails from PW using templates. This would provide a simple API for both sending these emails from other modules and templates and for retrieving their HTML output. A list manager for creating mailing lists based on criteria such as certain fields, a selector on $users or roles. Each list could have some associated settings such as default from address, etc. The lists are synced with either CM or MailChimp. The module would need support for websockets to receive unsubscribe requests from those services. A webmailer module that allows you to create emails. This would require the two above modules and feed the HTML for the emails to CM or MailChimp. I'll have think about the first of these over the weekend. Stephen
  • Create New...