wireshell - an extendable ProcessWire command line interface

[Mike Rockett]

The thing with Windows is that it doesn't automatically pick up the laravel command like *nix can, which is why a batch file needs to be created. However, because your wireshell file is looking for the vendor directory inside it's own, it doesn't work. As such, you'll need to change your request for autoload.php to this (the way Laravel's installer does it):

if (file_exists(__DIR__.'/../../autoload.php')) {
    require __DIR__.'/../../autoload.php';
} else {
    require __DIR__.'/vendor/autoload.php';
}

Then, the user can create a wireshell.bat file in a directory visible to the windows path containing this:

@echo off
php "%appdata%\Composer\vendor\wireshell\wireshell\wireshell" %*

This works on my side.

Update: If using mingw32 or cygwin, however, this isn't necessary - it's just a matter of adding %appdata%\Composer\vendor\wireshell\wireshell\wireshell to the path.

[marcus]

The thing with Windows is that it doesn't automatically pick up the laravel command like *nix can, which is why a batch file needs to be created. However, because your wireshell file is looking for the vendor directory inside it's own, it doesn't work. As such, you'll need to change your request for autoload.php to this (the way Laravel's installer does it):

if (file_exists(__DIR__.'/../../autoload.php')) {
    require __DIR__.'/../../autoload.php';
} else {
    require __DIR__.'/vendor/autoload.php';
}

Then, the user can create a wireshell.bat file in a directory visible to the windows path containing this:

@echo off
php "%appdata%\Composer\vendor\wireshell\wireshell\wireshell" %*

This works on my side.

Update: If using mingw32 or cygwin, however, this isn't necessary - it's just a matter of adding %appdata%\Composer\vendor\wireshell\wireshell\wireshell to the path.

Thanks for the support on this - I'll outline the cygwin scenario in the installation instructions.

/edit: Updated start post and WS to 0.3.1

[Mike Rockett]

Perfect - any time. Oh, and I made a mistake. When using cygwin/mingw32, the path is actually "%appdata%\Composer\vendor\wireshell\wireshell\". I added in an extra wireshell there...

[clsource]

Big update! Version 0.3.0 comes with:

• a new "NewCommand" provided by HariKT! Big thanks again. This contribution should lead to a better workflow with Wireshell since it opens up the possibility to install PW via command line in a convenient way
• A command for creating fields
• A command for assigning fields to existing templates
• A generic backup command (DB dump)
• Commands for en/disabling modules (downloading them via Wireshell is still on my bucket list)
• A little command outputting the currently installed ProcessWire version
• An unified approach to naming commands and classes: entity:verb, so for example user:create
• I dropped the "(Experimental)" from the topic's title 

Read more about the available new commands and their options in the readme.

If you have an older version of Wireshell installed, make sure you "$ composer update" it in order to get the new dependencies. And we're on packagist now: https://packagist.org/packages/wireshell/wireshell

So far so good .

for the command wireshell backup:db I suggest renaming it to db:backup 

so for example if you implement a db replace or db merge command in the future.

the command will became.

db:backup // Dumps an entire db
db:replace // Delete existing db and replace it with a backed one
db:merge // Merge the existing db with the data from a backed one

Again thanks for the great work.

[marcus]

So far so good .

for the command wireshell backup:db I suggest renaming it to db:backup 

so for example if you implement a db replace or db merge command in the future.

the command will became.

db:backup // Dumps an entire db
db:replace // Delete existing db and replace it with a backed one
db:merge // Merge the existing db with the data from a backed one

Again thanks for the great work.

Thanks! The idea behind backup:db is that backup is the entity/namespace, and you can specify:

:db for database

:files for /site/assets/files

:scripts for all scripts (/site + /wire + root files)

:all for :scripts + :db

[onjegolders]

Marcus, this looks fantastic, thanks for all your hard work!

[marcus]

Marcus, this looks fantastic, thanks for all your hard work!

Not hard at all - fun, as I'm dealing with amazing tools (ProcessWire, Symfony, Composer packages) and learn a lot on the way

[Hari KT]

Hey marcus, all, 

Is there anyone played with the importing / exporting of the fields and templates via json and keeping them on the module. May be we can make that a wireshell command . I was looking at continuous integration of fields and templates.

[Stikki]

This is freaking cool, keep up good work

[justb3a]

I've just started a new project and decided to test/use Wireshell.

After I had successfully created a new project I missed the opportunity to download modules. You've received a new pull request.   Maybe you have some time to test (and hopefully implement) it.

[marcus]

Just received the mail from GitHub! Nice! Trying it out over the weekend! Big thanks!

[owzim]

This seems to gain some traction, great job @marcus

[horst]

Finally I have had time to download it. Its simply fantastic and a lot of fun!

Regarding the windows users I share how I have set it up. Its only a bit slightly different than the very good explanation here from @marcus and @Mike_Anthony. I have done installation step 1 and 2, but not step 3. Instead of adding something to my path I simply created a single wireshell.bat file that I put somewhere into my already existing system path.

I also have no PHP directory accessible through the system path, because I use minimum 5 different PHP versions (3 for CLI and 2 with the local Apache). If there were one in the system path this can lead to weird behavior of PHP, at least with the old PHP 4 that I need for older CLI tasks.

My wireshell.bat looks like

@ECHO OFF
SET phpexe=C:\bin\php-54\php.exe
SET phpparams=-c C:\bin\php-54\wireshell\
SET wireshell=%appdata%\Composer\vendor\wireshell\wireshell\wireshell

TITLE WIRESHELL :: %CD%
"%phpexe%" %phpparams% "%wireshell%" %*
TITLE %CD%

With the phpparam -c I have specified a directory where the php interpreter has to pickup its php.ini. I have one setup that is different than I need with other CLI scripts. I also could have linked to the php directory what is running under apache. But unfortunately I switch this between php 5.3.8 and 5.4.x for modules testing currently. (and composer and wireshell needs minimum 5.4.0)

That with setting the title in the cli windows is nice if you have running several tasks. When hovering over the stacked icons on the taskbar, you can see which one is in "WIRESHELL mode" and which one is finished.

[marcus]

justb3a's great ModuleDownloadCommand has just hit the develop branch! Next, I'll try to incorporate Nico's module generator, and then both new Commands will be released as 0.4.0

@horst: Thanks for sharing your approach! Since the Readme and this topic's start post is getting bigger and bigger I'll set up a dedicated microsite for wireshell doc and best practices like these.

[dewwwald]

This is so cool!!

[felix]

marcus I really like where this is heading. keep up the great work!

[marcus]

Thanks, felix!

New on develop branch:
 

$ wireshell status

(Replacing ShowAdminUrlCommand, ShowVersionCommand)

Edited April 25, 2015 by marcus

[gebeer]

Thank you for putting this together. This is absolutely great

I came over from Joomla some time ago and one of the many joomla devs have created joomla-console. They combine it with their joomla-vagrant box which is a great tool for development. I am actually still using it for quick setup of PW projects  And I've been thinking for quite some time how great it would be to have a console tool for PW. And now it is here. So big thumbs up!

I see that there is some kind of naming convention for commands now. Have you ever considered renaming the 'new' to 'site:create' Thats what joomla-console uses and they also have a 'site:delete'.

[Mike Rockett]

I see that there is some kind of naming convention for commands now. Have you ever considered renaming the 'new' to 'site:create' Thats what joomla-console uses and they also have a 'site:delete'.

I think the context may be wrong. I don't know Joomla at all, but, to me, site:create would imply a multi-site environment, especially considering the existence of site:delete. Or am I wrong?

[horst]

@marcus, when I have read this about status, it came to my mind that we already have those Diagnostic Tools. Do you already know them?

Maybe it is possible to integrate some of the submodules into wireshell by calling status:(submodule)?

Edited April 25, 2015 by horst
added screenshots

[marcus]

That's a good idea!

Instead of status:submodule I'd suggest to add it as options, like:
 

$ wireshell status --php --filesystem --image --webserver

...and output each block/topic as a separate table (see screenshot above).

Without options wireshell status would just return the PW and wireshell info.

Either way: I'll look into Diagnostic Tools as soon as I finish 0.4.0 and the project microsite. Of course pull requests for this, maybe from the Diagnostic Tools creators & contributors themselves, would be highly appreciated

[gebeer]

I think the context may be wrong. I don't know Joomla at all, but, to me, site:create would imply a multi-site environment, especially considering the existence of site:delete. Or am I wrong?

In the joomla-vagrant context it makes perfect sense because with that command you can setup a new site in a subdomain so you can have multiple dev sites residing in one virtual machine. But I see your point when considering multi site environments.

[horst]

Of course pull requests for this, maybe from the Diagnostic Tools creators & contributors themselves, would be highly appreciated

Hehe, started!

[marcus]

People, this is really awesome!   

When I started this little project I had a little hope for community contributions a) because of the vibrant PW community and b) the modular architecture of Symfony Console, but I would have never expected this growth within a month. Big thanks to all contributing and fixing commands and ideas! 

@horst: Bam! Delivered! Cheers!  I'll look into it, merge it soon and will establish a proper namespace for the growing number of helper classes.

One more thing: I hate to have hobby horse projects without at least a rudimentary logo   


 

[horst]

what's about

  ?

wireshell-drafts.zip