Member Since 1 Year Ago
3,540 experience to go until the next level!
In case you were wondering, you earn Laracasts experience when you:
Earned once you have completed your first Laracasts lesson.
Earned once you have earned your first 1000 experience points.
Earned when you have been with Laracasts for 1 year.
Earned when you have been with Laracasts for 2 years.
Earned when you have been with Laracasts for 3 years.
Earned when you have been with Laracasts for 4 years.
Earned when you have been with Laracasts for 5 years.
Earned when at least one Laracasts series has been fully completed.
Earned after your first post on the Laracasts forum.
Earned once 100 Laracasts lessons have been completed.
Earned once you receive your first "Best Reply" award on the Laracasts forum.
Earned if you are a paying Laracasts subscriber.
Earned if you have a lifetime subscription to Laracasts.
Earned if you share a link to Laracasts on social media. Please email [email protected] with your username and post URL to be awarded this badge.
Earned once you have achieved 500 forum replies.
Earned once your experience points passes 100,000.
Earned once your experience points hits 10,000.
Earned once 1000 Laracasts lessons have been completed.
Earned once your "Best Reply" award count is 100 or more.
Earned once your experience points passes 1 million.
Earned once your experience points ranks in the top 50 of all Laracasts users.
Replied to Best Practices For Handling Emails?
Appreciate the response Bobby.
Just to clarify that I am getting the terminology right - you are recommending that I simply export a list of emails and import it into a third-party location for sending the emails, rather than using the built-in mail option in Laravel, correct?
Or are you recommending that I still use Laravel mail for creating and sending emails but send them via a third-party email provider (setup in my .env file). Sorry if this is a stupid question - this is all just totally foreign to me.
If you are suggesting the first option, wouldn't it be difficult to send emails automatically (like when someone abandons their cart)?
Started a new Conversation Best Practices For Handling Emails?
I recently started selling my first online product, and it has been successful, but I have done very little in the way of interaction with my existing and potential customers. I have a lot of users who sign up but stop before purchasing, and I would like to reach out to these users with an "abandoned cart" email.
Currently, I just use the laravel email engine connected to my sendgrid account to send receipt upon purchase and support emails. That being said, I know there are a lot of different ways to go about sending out marketing emails, such as creating a "campaign" inside your email server provider itself. What are considered best practices for a single developer/business owner to manage all of their email interactions with minimum room for error (I want to avoid sending out emails that get marked as spam or have formatting errors). Can anyone share their personal workflow in the email domain?
Started a new Conversation Alfred Alternative For Windows?
I just realized that this is probably a great place to ask this question - I'm assuming the majority of laracasts viewers are familiar with Alfred from its constant appearance in laracasts videos.
Has anyone found an alternative for windows that switches to the active window? I've found a bunch of alternatives, like Wox and countless others, that will allow me to launch an application just like Alfred, but I am almost never looking to launch an app - I'm looking to quickly and easily switch to an application that is already open.
The closest I have gotten is Wox + the plugin "Switcheroo," but this plugin requires you to type an action key before the program name to indicate you want to switch to the open window and not launch a new one, and I don't want to destroy my mac muscle memory. It says I can use "*" in its place to remove the need for an action key but I cannot seem to get this to work. I've spent more time than I care to share seeking this functionality.
@BRAUNSON - I really appreciate you taking the time to write this, but I'm afraid it doesn't answer my question. Let me see if I can rephrase it:
I cancel the user's subscription in BrainTree. Then, I delete the subscription from the subscriptions table. Then, I create a new subscription in BrainTree. Then, I manually add a row to the subscriptions table with all the data. Bam, user has a new subscription now.
I have already done the above and tested to ensure it works (->subscribed returns new subscription). All I am trying to figure out is if I will run into issues in the future (such as when user tries to cancel) by adding a subscription manually like this, or is the process I described above an exact replica of what Cashier is doing when it creates a subscription?
The reason I am suspicious that something may go wrong is because I have no idea how cancellation actually occurs in Cashier. For example, if I cancel my subscription right now, nothing actually happens in the BrainTree back end. The subscription does not show up as cancelled until the billing date is reached. How is this happening? Is there some sort of script being run at the end of each day to check all of the subscriptions in the database to see if they have ended before telling BrainTree to cancel? That is where my confusion lies.
@CRONIX - Regarding the first point, about it not communicating with BrainTree - I meant to include that I would manually cancel the subscription on the BrainTree back end.
I agree that using Cashier for all of this functionality makes more sense, but also consider that this is just a one-time use. I need to perform this functionality on three accounts just one time, and will not need to perform it again in the future. For that reason, I'm trying to find the quickest and easiest way to accomplish the task of adding 5 days of credit to 3 of my users.
Is there anything wrong with simply doing this:
I'm just trying to figure out if Cashier is doing anything else under the hood, besides the 4 steps above, to make everything work. If that's all it's doing, I would much prefer to manually do this right now than take the time to figure out how to do this programmatically because I will never need to do it again in the future. I would literally delete the methods as soon as I used them on these three accounts.
I'm the last guy to say, 'hey I want to waste time doing this manually risking multiple points of failure when it could be automated,' but it's such an unnecessary thing for me to code at the moment. Not to mention, I'm completely unaware of how to create a subscription for an existing user using Cashier without having to provide a token with their payment details - tried already and realized it was more complicated than I anticipated.
Started a new Conversation Manually Add A Subscription To Laravel Cashier
Let's say I manually create a new subscription for a user in the BrainTree back end. Can I integrate this subscription with my Laravel Cashier by simply manually inserting a row into the subscriptions table with all of the relevant information (subscription ID, ends at, etc.)? Or is there more going on when you call newSubscription?
@BRAUNSON - This may be a stupid question, but I have no idea how Cashier actually works under the hood so I'll just ask it anyways.
Is there any difference between using the cancel subscription method and just deleting the entry from the database?
Likewise, is there any difference between using the BrainTree PHP library to make the subscription rather than just manually creating the new subscription in the BrainTree back end and just inserting a row manually into the subscription table with an insert statement?
I guess what I'm trying to get at is - are there other things going on under the hood when you call subscription cancel or newSubscription that hook up the two?
@BRAUNSON - Unfortunately, I only need to use this functionality for users that are already signed up. It is not a feature I will ever need at initial sign up. On the bright side, I don't really need to do this programmatically since it's a one-off thing. Just need to glue this together for a couple of people in this instance.
After speaking to BrainTree, it appears my only option to change the date they are charged is to cancel the existing subscription and create a new subscription with a trial period at the beginning and link it to the same payment method as their original subscription.
This brings me to the second part of the equation, making this work with my Cashier implementation. Does it make sense to simply manually add a subscription to the subscriptions table in Laravel with the relevant braintree_id created on the BrainTree back end from the subscription manually created above, and then set the trial_ends_at to match BrainTree's trial_ends_at? It seems like this would work, but I don't fully understand Cashier so maybe there is something wrong with just manually adding a subscription like this.
So for example, I'm imagining: I have a user whose subscription ends on the 28th, but I want it to end on the 30th. I cancel the existing subscription on the BrainTree back end, and create a new subscription starting now with a trial that lasts until the 30th. Then, in Laravel, I delete the old subscription entry and manually insert a new one with the new ID and set trial_ends_at to the 30th.
Started a new Conversation Laravel Cashier - Adding Days To Subscription
I am a totally newbie to both Laravel Cashier and BrainTree, and I am trying to figure out how to add days to a person's subscription (meaning offset the day they are charged again by a certain amount of days).
Upon reading the Cashier documentation, I see that there is a feature called 'anchorBillingCycleOn' that allows you to change the anchor date of the subscription, but this is only an option in the Stripe version of Cashier.
What can us BrainTree Cashier users do to make it so our user's subscription is charged a few days late?
Started a new Conversation Laravel Cashier Cancelling Subscriptions
Apparently, it is not supposed to show a subscription as 'cancelled' in the BrainTree payment panel until the ends_at date in the subscriptions table is reached for that subscription - it is just supposed to show as active until the exact point when the user would have been billed again, at which point it is changed to inactive.
Is this true? This is super confusing to me, but I tested it with the cancelNow() function and it did indeed update on BrainTree immediately, but of course those people who have cancelled with time remaining on their subscriptions are still showing as active in BrainTree.
Am I explaining the intended functionality correctly? This is just scary to me because I don't want any of my users to get charged if they cancelled for obvious reasons.
@SNAPEY - Wow, this looks exactly like what I was looking for. I came across a couple of similar things but I really trust this community a lot more than I do Google search results, so thank you for this. Going to eat this content up.
Started a new Conversation Resources For Learning How To Manage Server Resources?
I got lucky - I made an application and it turns out there are some people who actually want to use it. I never thought I would get this far.
My application is based around retrieving information from a database with about 80 million rows. The database is heavily indexed, and the information in it is static - it isn't written to, except with user account data. The people using my application are performing search queries on this database essentially once every couple of seconds.
Currently I am running the website through Forge on a Digital Ocean droplet with 3GB of RAM, 1vCPU and a 60GB disk. The point of this post is: I want to learn how to monitor the performance metrics on the server and know if/when I will need to upgrade things like RAM and CPU.
I've been watching the graphs on Digital Ocean and so far everything seems fine to my ignorant eyes, but then again I really know nothing about this area. CPU usage is rarely over 5% and memory usage is a steady 16%. Disk usage is sitting at 37% and the disk I/O has spikes of up to 350kb/s pretty frequently (no idea what this means). The bandwidth public gets spikes of .05mbps frequently, and occasionally a large spike to .36mbps. Those are all the graphs at my disposal.
Is monitoring those graphs all I need to do to ensure I always have enough "juice" to power my application as my number of users increases? What is a good resource to learn how to monitor my server's load and how/when I need to upgrade different components of it? Appreciate the help in advance guys.