In Opencart 1.5.X email notifications for new order\customers\etc was implemented via catalog/model/checkout/order.php in confirm() method.
But in OC3.X this code was completely rewrited and I can not find how this functionality is implemented in this version.
Your list of notifications implements in different places. Email notifications mostly implements in /catalog/controller/mail/
There you can find affiliate, forgotten, order, register and transaction.
Each controller related to one or more different models. You can find a related models using search in these controller, looking for $this->model_.
For example /catalog/controller/mail/order.php contains references mostly on /catalog/model/checkout/order.php ($this->model_checkout_order).
Related
I'm currently working on a laravel app.
The same app is already running on wordpress and through the laravel application we are going to add some additional features in original application.
The laravel will run on the subdomain.
Here is the thing:
On wordpress website, we are publishing different public articles but on the publishing of these articles we need to send an email to either "all employees" of company or "all managers" of the company.
The company employees detail is stored and available in laravel.
I was hoping that there'll be a way through which on article publishing, I will give two options to the user on wordpress: "Send email to employees"/"send email to managers" and on selection of any of the option, email send event will be triggered from my laravel website.
I've almost no experience of wordpress. I was trying to google it but couldn't find any helpful links.
WordPress works quite different then laravel, and is working with many hooks..
You could monitor post status changes with: https://codex.wordpress.org/Plugin_API/Action_Reference/publish_post
You have to implement the email sending your self inside this hook,
And also trigger a webhook against your laravel endpoint.
The publish button in wordpress does not allow you to select who to send an email.., But this can be build with custom fields / meta data on your post.
Quite depends on how you would like to implement that.
Unfortunaly WordPress does not work with composer by default therefore you don't have an easy way to get packages like Guzzle to send your request to your larvel endpoint.
WordPress has some build in methods to do REST calls, see:
https://developer.wordpress.org/reference/functions/wp_remote_request/
I've read the page about the new notifications in Laravel 5.3, and seen some tutorials from Laracasts, but I would like to know what is available in terms of variables etc.
In the Slack API documentation, I can see that I can create buttons in the notification, however, the notification (using SlackMessage) shows that I can't use action() and it throws
Error
Call to undefined method Illuminate\Notifications\Messages\SlackMessage::action()
Does anyone have some information about this?
Thanks in advance!
What I think is you are reading the documentation wrongly. According to Laravel's Slack Notification, it doesn't help you create "button" in Slack.
The Laravel Notification is a mechanism for you to create notification through different channels, like SMS (Nexmo), Database, Emails, Slack. So if you think about this carefully, "button" is actually not a common pattern in these channels, hence action is not implemented here in Slack.
In contract, the action method found in SimpleMessage or MailMessage is actually referring to "call-to-action" button. It helps you create a button in the email nicely. This is not true in other type of notifications, such as DatabaseMessage, NexmoMessage, or SlackMessage. You simply don't (or doesn't make sense) to create buttons in these channels.
If you need to create additional content with SlackMessage, simply extend it and build one for your own.
I read laravel documentations about Events and Notifications, it seems we can fire an event and from that event (using ShouldBroadcast interface) broadcast it to laravel echo which i understand, in the other hand we can use Notifications viaBroadcast to do the same, so what's the difference?
What the provided answer lacks imo is that they are in most cases used both instead of 1 or the other, which seems to be the tone of the provided answer/question.
An event is something significant in your application. Let's assume your application is a Webshop.
A significant action in your webshop can be Product Purchased . When a product is purchased you need to do a lot of different steps. Putting this all inside a controller and potentially in several different places can get very messy and not clear.
So a good approach would be to use a Event called ProductPurchased . This event can have Listeners, those listeners are in this case all the steps you need to perform when a user purchases a product.
e.g.:
ProductPurchased (event)
BillClient (eventlistener)
GenerateInvoice (eventlistener)
notifyClient (eventlistener)
...
Let's say we want to notify our client with a text-message and an email when they purchased a product.
So on the notifyClient event-listener we can create a Notification . This notification is responsible for sending a message to the client. This can be a SMS/Slack-message/Email/...
And like you mentioned both Events and Notifications can be put on the Queue or can be broadcasted. Broadcasting is mainly used in combination with Laravel Echo and the use of Websockets.
You choose notifications when you want to send something to different channels. Mail/SMS/Slack..
If you only need broadcasting you can just use ShouldBroadcast. Just like when you only want to send an e-mail use Mail:: without the need for a notification.
Notifications are a nice way to group the same 'message' to different destinations.
After thinking a lot, i found out that they are made for different things, here's what i understood:
Notifications:
Consider facebook, everytime you login you see bunch of notifications about things that happened while you where away, also if you are present you see live notifications..
meanwhile you're getting emails about notifications that you want..
this is exactly what Laravel Notifications is doing.
you can use notify method on your eloquent models such as App\User about something like OrderApproved which will do whatever you planned it to do for you like sending sms to that user. and also you can save one instant of that notification on database so when user comes back he or she can see that you have approved their order..
Events:
it's when something happens, like when a new user is created and you want to do different things like sending verification email, sending verification sms and.. this is why you create an event so that you could handle different logics of that event using listeners.
when it comes to broadcasting, you can use ShouldBroadcast interface on your event and from there you can sync data with your admin panel that a new user is registered. this will be useful when admin is watching list of users and without reloading the page you could user Laravel Echo to receive that event on admin panel and append new registered user to the list.
Conclusion:
it really depends on what you need, if you just want to update something in your interface, maybe events are what you need. but if you need to do more you can use notifications.
in the end events are used when you need to do things when something happens while notifications are report of what just happened.
hope it help others..
I'm trying to come up with a generic way to add multiple implementations of payment providers in a system that only uses one for now.
I'd like to have a Company object linked to a Subscription. A Subscription has multiple Invoice objects connected to it. A Subscription can only have one PaymentProviderInterface linked to it but we have to option to replace the payment provider for the subscription. The PaymentProviderInterface linked to the Subscription is build by a Factory.
The problem is that for different PaymentProviderInterface implementations the logic to get the user to be notified might be different. For a special PaymentProviderInterface an email must me send to our system instead of the actual end user. For Stripe the email should be send to the user connected to the Stripe account. For another service the user is stored in the Company object.
Is there a way to implement this without the PaymentProvider object having to actually know about the Subscription it's linked to?
The same thing for the BillingAddress. The way we retrieve the billing address to put on the Invoice object is different per payment provider. If it's Stripe, it's the billing address stored on Stripe. If it's another one, the BillingAddress is stored in our database.
You should be able to define custom arguments passed to the payment provider as parameters of the query and returned to your server "as it" after a payment attempt (wheter it is a successfull or failed attempt doesn't impact the presence of these custom args). When your Factory elect the right PaymentProviderInterface for the Subscription, it can then select the User using the logic you want and pass it as parameter to the PaymentProvider (as a string), then the server can know who to notify based on what's returned by the PaymentProvider by parsing the content of this custom arguments field. Custom Arguments in PaymentProviders are usualy used for this kind of purpose.
Does this makes sense ?
I guess that the concept of Observer design pattern is one of the possible solutions that you're after for. Since it main purpose is to ensure a way of notifying change to a number of classes. It defines a dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
You can consider following implementation:
Subject (Subscription)
knows its observers. Any number of Observer objects may observe a subject
provides an interface for attaching and detaching Observer objects.
ConcreteSubject (ConcreteSubscription)
stores state of interest to ConcreteObserver
sends a notification to its observers when its state changes
Observer (IPaymentProvider)
defines an updating interface for objects that should be notified of changes in a subject.
ConcreteObserver (PaymentProvider)
maintains a reference to a ConcreteSubject object
stores state that should stay consistent with the subject's
implements the Observer updating interface to keep its state consistent with the subject's
I would like to do a site in PHP/MySQL using either Drupal/Joomla/Wordpress that allows me to have class list with description/date and students can sign up to pay for it. I prefer Wordpress if there is some package already. The idea is to have students to pay via Paypal. For backend, Admin should be able to manage class, check students status.
The reason I want to do this is because I have a small company and I want to do special workshop once in awhile.
Any recommendation on something already built close to this?
You can accomplish this with WordPress and one of several event registration plugins. These two plugins integrate with paypal
http://wordpress.org/extend/plugins/advanced-events-registration/
http://wordpress.org/extend/plugins/event-registration/
Check out this blog article that mentions more plugins for event registration
http://www.moongoosedesigns.com/event-and-event-management-registration-plugins-for-wordpress/
http://eventespresso.com/ is the evolution of advanced events registration. It's good, and does exactly what you need. I use it for just that on firstlineeducation.com