Not at all. I just expect thing to be up to a certain standard. I am perfectly happy here using Composer to install Yii extentions which come as part of the official Yii release. I no longer at all trust anything from other developers.
Not at all. I just expect thing to be up to a certain standard. I am perfectly happy here using Composer to install Yii extentions which come as part of the official Yii release. I no longer at all trust anything from other developers.
You started this thread saying you need extensions from other developers installed yourself.
But you do not want to follow the Yii2 recommended way and do not want anything like composer
Now you are suddenly saying you are ok with doing all with composer but now you do not trust any developers or their extensions
Summary: You are very contradicting in each of your statements.
Do not know about your trust on developers, but no one will trust your words or your questions, or even be forthcoming to provide help… until you are humble enough in your search for accepting knowledge.
This thread is getting out of hand!
Backslider decided to use Yii and can use it in any way he or she wants. Regardless of whether or not ‘Resistance to Change’ exists, backslider ultimately controls his or her development workflow and application maintenance. You made some good points, but…
Composer is not a cure-all solution for all vendor-related updates. Its usage needs to be tightly controlled at the developer level. For a distributed application, you would not want any Tom, Dick, or Harry performing any updates of vendor files that might effect application-specific extensions of that code. For example, an application may include an extended ActiveRecord class that might be affected by new releases of the parent ActiveRecord class. Developer testing is required to determine if the extended class needs to be updated or not before performing the Composer update for distributed applications.
For a distributed application, some internal installation and dependency management might need to exist in order to automate installations and updates after developer testing.
I personally use the backslider approach for numerous vendor files because I either needed to hack the original code, extend it or replace portions of the code. For example, I store my vendor supplied editors in their own subdirectories under extensions/editors/ because most have been modified to incorporate application-specific buttons for accessing my file repositories (images, videos, boiler-plate text, etc.) or custom plugins. I also enumerate the editors directory to determine what editors are available so a user can select one or more editors from their user profile. I’m sure other developers have similar requirements.
Get a life mate. Your problem is that you do not take the time to comprehend what others are saying and get off on trolling people on the internet.
I have now developed a new way of installing extensions - first I test the composer install in a test environment that I have specifically designed for this.
If all is ok, I install where I need it using Composer. If it’s not ok I reject the extension outright.
I agree that Composer is a nice way to do things, but when things go wrong it is a total pain… and things DO go wrong.