-
Posts
289 -
Joined
-
Last visited
-
Days Won
8
Posts posted by marcus
-
-
Just received the mail from GitHub! Nice! Trying it out over the weekend! Big thanks!
-
Amazing tool, looks massively helpful! Thanks!
(Could we put your generator into a wireshell command, kind of like Mike suggested some days ago?)- 4
-
i copied the file content into the htaccess.txt and i still get the same result.
Misunderstanding: rename htaccess.txt to .htaccess
- 1
-
Add the contents of this (being the necessary original contents of PWs htaccess) below the line you discovered:
https://raw.githubusercontent.com/ryancramerdesign/ProcessWire/master/htaccess.txt -
Is a .htaccess file present in the root of your project?
-
In these cases I'd give the pages menu-1 and menu-2 a template, consisting of:
<?php /** * Template: First Child redirect * */ if($page->numChildren) $session->redirect($page->child()->url);
So that a click on them redirects to menu-1-1 or menu 2-1 respectively.
More: https://processwire-recipes.com/recipes/quick-first-child-redirect/
-
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
- 7
-
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
- 3
-
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
-
On Windows, it installs to C:\Users\<user>\AppData\Roaming\Composer\vendor\wireshell\wireshell\ ... Not sure what the best way of making this global is, other than making a batch file look specifically in that directory. I must admit: I'm not a composer fundi, but I get the basics...
Update: In fact, if I run wireshell directly from the above directory (using php wireshell), it doesn't run because it's looking for vendor/autoload.php in that directory too. If I run the nasty php vendor/wireshell/wireshell/wireshell from the C:\Users\<user>\AppData\Roaming\Composer directory, it works. Phew, quite messy. But, like I said, I'm no fundi - there must be a better way to do this.
Thanks so far! I discovered an installation guide for "laravel install" on windows: http://www.bitspedia.com/2014/09/how-to-install-and-make-first-laravel.html :
- Add your ~/.composer/vendor/bin path into Path environmental variable, so that Windows Command Prompt could identify laravel command that would be used later to install Laravel and doing other tasks. In my case the path where its located is: C:\Users\UserName\AppData\Roaming\Composer\vendor\bin
so I added it into my Path environmental variable. Must restart your Shell or Command-Prompt so that updated Path variables is loaded.
And when I googled "windows Path environmental variable", got this: http://www.computerhope.com/issues/ch000549.htm. This GUI/matrix seems to be the counterpart to .bashrc.
-
-
Great! Thanks for this, Marcus. So far, everything looks good here on Windows - have only just installed PW-dev, going to work with other commands now. (Update: Everything works like a charm. Looking forward to seeing more Commands.)
For Windows users interested in making this global:
- Make sure PHP is in your PATH
- Create a wireshell folder somewhere (also added to your path), and create a wireshell.bat file:
@echo off php "path\to\wireshell" %*
Then you can run wireshell new --dev anywhere you like.
Since Wireshell is on packagist now and "composer global require wireshell/wireshell" installs it into "~/.composer/vendor/bin/wireshell" on Linux, could you test/check what the comparable Windows path or workflow would be? I'm currently rewriting (simplifying) the installation guide. Cheers!
- 2
-
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
- 14
-
Thanks for the proposals regarding an installer process, @HariKT and @Richard. A command named "new" definitely promises more than a download, that's right. But for this command I was just tipping my toe in the water, and testdriving the Console component, mimiking "laravel new" (which actually just is a download since there's no installation in the classic sense). Actually your thread about a command line installation of PW got me started with Wireshell in the first place So it's really cool that you'll contribute. Looking forward to the PR!
@Richard, it would be cool if you can post your approach to this. Frankly speaking I'm still in the learning phase regarding whats really possible with the API and would be glad if we could discuss in this thread the best approach about this - probably - most important command of Wireshell
- 1
-
Not sure if this can be done with Symfony Console (I've never really looked at it before), but what about `create:user`, where a colon is used?
Good idea, totally possible and artisan-y.
- 1
-
Seems like you put the same alias for 3 commands...
Nope, but since the other two also start with cr.. Console component tends to misunderstand cr as an incomplete command.
-
Ever since I learned about drush I knew PW could benefit greatly from similar tool. Great job, Marcus!
Those "with dashes in-between" comands look a little weird for a cli interface. I saw you can easilly add aliases for commands, so maybe cr showd be included as a third one (as it is quicker to type)? Drush commands comprise of an object being manipulated followed by a "manipulation type". Not saying it is the right way to go, but it is better to choose some naming pattern explicitly.
Wireshell is a bit long too... Why not add an alias like ''wish" (for WIre SHell). It sounds magical, and isn't PW a wish come true?!
Thank you for developing this!
P.S. It kind of bugs me a little that this cli tool is written with symphony, not with PW itself. I am not even close to being able to argue here, but can it even be done?
Regarding aliases: Yeah, I'm aware of the dash, and wanted to try cr, cu, ct first, but in the case of "cr" Symfony Console bugged me with the following error:
So in favor of consistency (cu. ct. cro?) I went for the dash.
As for "$ wish", that was also my first thought (especially regarding the pun), but I learned that - at least on Unix and OS X - there's a programm called "wish" already present (https://www.tcl.tk/)
/ Edit: and I'm totally open for a "command style standard". The current order "verb-noun" was nothing but a gut decision.
-
Thanks for the positive feedback!
Some updates in 0.2.0:- Attach roles on the fly while user creation: $ wireshell create-user foo --roles=superuser,editor
- Create templates and attach existing fields on the fly with $ wireshell create-template contact --fields=body,sidebar , prevent template file creation with --nofile
- Command aliases now available: c-u, c-t, c-r, s
Now planning field creation.
- 6
-
wireshell 1.0.0 is out
Quotewireshell 1.0.0
Compatibility: ProcessWire 3.x
- Prepares wireshell for ProcessWire 3.x, adds namespace support, only supports ProcessWire 3.x
- Updates Github Repository: github.com/processwire/processwire
-
Improves
module:upgrade
command, if no argument is provided it just checks for upgrades -
Extends
new
command, adds option--src=path/to/source
to be able to use a pre-downloaded tgz/zip/folder -
Extends
status
command, only shows database password if--pass
option is provided, shows if an upgrade is available -
Updates
upgrade
command, removes options dev and devns
Now this one could be a rather long post about only an experimental niche tool, but maybe a helpful one for some, so stay with meIntentionDo you guys know "Artisan" (Laravel) or "Drush" (Drupal)? If not: These are command line companions for said systems, and very useful for running certain (e.g. maintenance, installation) task quickly - without having to use the Admin Interface, first and foremost when dealing with local ProcessWire installations. And since it has a powerful API and an easy way of being bootstrapped into CLIs like this, I think such a tool has a certain potential in the PW universe.It's totally not the first approach of this kind. But: this one should be easily extendable - and is based on PHP (specifically: the Console component of the Symfony Framework). Every command is tidily wrapped in its own class, dependencies are clearly visible, and so on.( Here was the outdated documentation. Please visit wireshell.pw for the current one )- 33
-
Ryan:: my website this problem please help me
This request was aborted because it appears to be forged.
Please take a look into the Troubleshooting Guide
-
During developement, use...
<meta name='robots' content='noindex,follow' />
...in the future and remove this tag before the Going Live.
- 3
-
Haven't found the time to install it and fiddle with it yet - but this looks exactly like the module I was describing in the original post, including solution via sub tree with references.
Thanks!
-
-
I see, this one needs a whole lot of cooking before it gets into the recipe book
- 2
-
Nice one! For larger installations and/or a larger set of roles this will really be a boost. As for naming, I'd root for "Permissions Overview"
ProcessWire on the web
in Pub
Posted
Haha, talking about biased comparisons - And we're holding back...