Member Since 7 Years Ago
3,245 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.
Earned once your experience points ranks in the top 10 of all Laracasts users.
Thanks again - I'm not familiar with that concept - some reading and learning to do!!
Thanks Martin. I started down this path on the basis of trying to share the whole project between two sites, each with different branding and subtle differences.
The alternative was to have the entire project as a package or to make different branches in a repository to share the code.
At the moment I have two nearly identical repositories, I update one then later on update the other one which i don't think is the easiest way of doing this, hence the package route.
Maybe I'm overthinking?
Started a new Conversation Package Development And Relying On Other Packages
I'm trying to break an app I've made into modules by breaking it up into packages. I'm hoping this will make it easier to maintain the functionality and develop further - but getting confused in a couple of areas. I'm new to developing as a package and currently focussing on one piece, effectively copying and pasting existing code into the package folder and trying to get it to work. I'm using
jeroen-g/laravel-packager to help with development which includes
For now, my app until now has used the 'spatie/laravel-permissions' package to protect functionality and routes etc.
I'm now trying to test a controller in the package based on a test I had in my original whole project and working through the test failures which is mainly around setting up the test environment.
My latest error is that a
config/permissions.php is not loaded. So a reliance on having that package set up properly in my package - which is where I'm starting to feel I'm doing this wrong.
I can't see a way of publishing a dependant packages config file from within the package development - equally not sure I should as this has potential to add a conflict or lack of flexibility in the final project that relies on my package.
My question then is where a package includes views and functionality that need protection through roles, should I rely on the final project to worry about that or should I use this package as I am at the moment but how do I configure for the development environment?
What's the best practice of bringing in other packages into a package to add functionality - is this a bad practice?
Hadn't thought of that one - In this case though I think I'll need to keep separate, it's not necessarily complex app but I have unique databases for each site (I could change connection based on environment I suppose).
[Appreciate I've not given much in terms of detail on the app]
I think in this case I want to keep the separation between the two
I thought about that and wasn't too sure whether that was the right approach given 90% of the code for the entire site would be in a package leaving just the config files in the main app.
Will explore that further - maybe that's what I should do if nothing else to get me to organise my code better
Started a new Conversation Understanding Approach To Reusing Existing App (git/env/config)
Hi I have two sites which effectively use the same code base (99%). At the moment they are in separate repositories on Git and have developed independently of each other - often duplicating code and loads of copy and paste - which I appreciate is bonkers.
So, I'm trying to bring this into one repository that the two sites will then "share".
Each site though has unique features such as name, branding, third party services (twilio etc) and admin email addresses etc.
For the most part I can place the passwords etc in a .env file to keep them unique.
So a couple of questions:
I've thought about developing the site into a package but it's quite extensive and I've not done any package development and due to my poor development ways breaking up into separate smaller packages might be difficult.
Any suggestions on how to approach and start to make my life easier?