Composer the way the license key is used in your article I must have a remote repository

I read your 2016 article on updating with composer. I'm new to this and still trying to understand the setup. https://premium.wpmudev.org/forums/topic/update-plugins-via-composer. The way WPMUDEV has implemented composer support does it require me to maintain a remote repository? Everytime there is an update for your plugins I need to login to the remote repository and run a script with my API key to update the repository? I have ready everything I can on these topics Including all the articles in SmashingMagazine and Torque but I'm still confused over how this all works. Can you suggest a soup to nuts article or tutorial that uses basic tools (everyone seems to have a whole list of hosted and semi-hosted add-ons). I'm using git, bitbucket, composer and I have external contractors including in-house developers and we all need to have access to the entire development environment which includes your plugins. Thanks

  • Huberson

    Hello Jerry
    Composer install method doesn't require you to have a remote repository. In short, your WordPress site is like a repository itself once you initialize composer.

    Since you mentioned you're using Git and composer, I assume you're already using command line in your process, so I will avoid the details about that.

    Basically, you only need to create a 'composer.json' file from the site root directory(next to wp-config.php),
    1- Give it a name and description(optional)

    "name": "any/unique-name",
    "description": "Optional description of the repo"

    2- Add wpmudev composer repo in the file

    "repositories": [
    		{
    			"type": "composer",
    			"url": "https://premium.wpmudev.org/"
    		}
    	]

    3- And add any of our plugins(or any WordPress plugin that support composer) in the "require" block with the version you want installed.

    "require": {
        	"wpmudev/forminator-pro": "1.5.3",
        	"wpmudev/wp-defender": " 1.9.*",
        	"wpmudev/wp-hummingbird": "*"
    
        }

    This is a simple example of composer.json file that install a "specific" version of Forminator, Defender and Hummingbird.

    {
        "name": "any/unique-name",
        "description": "Optional description of the repo",
        "repositories": [
    		{
    			"type": "composer",
    			"url": "https://premium.wpmudev.org/"
    		}
    	],
        "require": {
        	"wpmudev/forminator-pro": "1.5.3",
        	"wpmudev/wp-defender": " 1.9.*",
        	"wpmudev/wp-hummingbird": "*"
    
        }
    }

    Once you have composer.json setup, you then need to run 'composer update' command from the directory where you have the file. That will then prompt you for username, which is your wpmudev api key, and request you to save the key so you don't have to provide it on every update.

    Adding additional plugins only require adding a new line with the plugin name in the 'require' block. And run 'composer update' again(note, no authentication requested on subsequent updates if you saved the key).

    Feel free to let us know if any additional details needed.

    Regards,
    Huberson

  • Jerry

    Thank you but I understand the above I apologize I was not clear. When you say that I run composer update with my username (api key) how does that work if I have a contract developer. Consider this use case:
    - I award a project to contractor A to build a new plugin that uses data from one of your plugin's tables. (please ignore if the use case is not feasible.)
    - I grant the developer bitbucket access to my dev bitbucket repo what does the developer run (assuming my dev repo has the composer.json file in it.) so that the developer doesn't need my api key to get a working development environment to build and test the awarded project on their local machine..

    Thanks

  • Huberson

    Basically, when you run composer update and provide your WPMU API key, the prompt to save the key adds it in your home directory on the server where you ran 'composer update' .
    By default the key will be saved to auth.json file(~/.config/composer/auth.json) which is kept on your server only(not in composer.json file that can be checkedin to your repo).

    In general, our term of service doesn't really encourage sharing your credentials with other parties. So in the scenario you mentioned above, to avoid having to share the API key with developer, one approach is to create a staging environment on your own server and allow developer/contractor access to it(SSH/FTP) to work on any project needing the API key.

    The developer will basically work locally as usual, then push his changes to the staging to test them.That should also make it easier to push changes to production.

    You could save the API key in a location that is tracked by your remote repository(like in composer.json). But that would mean sharing the key with anyone with access to the repo.

    Cheers,
    Huberson

  • Jerry

    Thank you for answering my original question which means setting up a remote repository due to WPMUDEV's approach to composer and the API key. I don't want developers to work on our DEV server as that creates problems of its own (tried that). I've been concerned for awhile with WPMUDEV and its suitability for our needs. WPMUDEV is not really configured for a organization with in-house and contract developers that don't want third party tools like the dashboard in their production environment or they require API keys that can't be turned on or off when the project is complete (such as using ssh keygen files). This is no complaint, just a realization. I assume 95% of your readership are small businesses with small or local development resources.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.