Laravel is good. It was made from Symphony components.
It does definitely seem like someone was asked to check a house of cards for stability.
However, it’s somewhat like asking a uniformed home inspector to check a house with a known gas leak. If the house explodes because the inspector later decided to light a cigarette, whose fault is it when the how goes up in flames?
It’s a definitely unfortunate state of events but you’ve got to CYA when anyone is potentially subjecting themselves or a company to potential situations that can go wrong in a hurry. The smart inspectors ask the home owner to disclose all such problems before work begins and have paperwork in place that explains what they’re not responsible for when it’s learned that the owner was not entirely forthcoming. There’s typically even a “Force majeure” clause in such contracts that covers a “chance occurrence, or unavoidable accident” like this.
Sure the house might have eventually blown up anyway if the gas remained on. It also wasn’t a great idea to start smoking in the home even thought that in itself typically wouldn’t result in such a destructive outcome. The house would have come down by an (otherwise innocent) inspector’s decision to smoke in the house. The switching of tabs shouldn’t have the effect it did but the fact is that it did.
Unfortunately, it’s an elite author who has been featured. It was his employee that made the mistake,
Ah, that makes more sense. So hard to get good help these days…
If my employee was modifying a client’s site as an agent of my company then I’d expect to be responsible. If the author doesn’t want to be responsible in such situations, then the company should expressly avoid directly modifying client sites or involve some sort of a waiver of liability IMO.
It’s a risk you take when you update someone’s live site. With so many ways to mitigate liability, it sounds like it boils down to simple carelessness on the part of the elite author’s agent (who may not even be a developer). Of course, I must offer this simple disclaimer – IANAL and likely don’t have all the facts.
I’ve got a TB capacity account and have no issue uploading large files to them. When I use my desktops, sometimes it’s so quick that it doesn’t even give me time to make coffee! My other (mobile) devices vary in speed by their respective hardware capabilities and connections strengths.
Though I don’t sync everything and use the Selective Sync to prevent additional background syncing of files that I don’t want to wait for and might slow syncing down.- https://www.dropbox.com/help/4456
This seems like no developer / designer I’ve ever heard of. Not in title anyhow. Sounds more like this was likely an inexperienced wannabe playing at being a developer / designer. If they knew anything, they’d have tried on such a change on a (local) staging site first. They also should have not been mixing content with layout like that as it’s extremely bad practice. Very fragile, makes site extra vulnerable to breaking. All all such PHP should eventually be removed from the backend and put where into shortcodes or where it belongs. These things would have likely prevented this outcome. This is a terrible way to learn about these things. I hope the parties involved have at least learned what not to do and can now avoid such situations in the future.
This is why i don’t bundle third party plug-ins with my themes :]
Nothing wrong with bundling as long as themes and plugins are kept separate. There’s just a right and wrong way to it. If you’re including the code of the plugins directly in your theme, you’re just doing it wrong.
Another proof that we should not be bundling plugins into our themes. When will Envato act in this matter?
Please clarify what you mean by your use of the term “Bundling”. I don’t see it as proof but more like a “red herring” instead distracting from the real task / issue at hand here.
Taking separate plugin code and bundling it into the core part of any theme / framework rather than continuing to distribute it as a separate plugin is indeed bad. Distribution as a separate plugin (via TGM, etc) prevents a set of greater evils though IMO. If you prevent authors from re-using existing code then you’re not asking them to duplicate the efforts of others, you hold back progress / innovation and you’re not creating any kind of standards (think pre-industrial revolution / non interchangeable parts in US and other developed countries) as everything essentially becomes proprietary (regardless of it’s open source nature) and that promotes even more theme lock-in (which only benefits authors / envato, not buyers).
Envato really doesn’t need to act on your specific point. They merely provide the platform to sell. To tell authors they can’t use plugins in their themes is taking away choice and another move towards a dictatorship. It’s totally up to the authors to provide the updates and keep their customers updated / protected whether that be through an auto-update system of their own design or one that Envato provides. Plenty of authors already bypass the Envato update queue today for critical fixes so that’s not much of a concern. Even when the end user is made aware of a situation / understands but still doesn’t update, that’s on them. Whether they take responsibility for it or decide to put the blame on someone else is a another matter.