Leaderboard

I confirm this. This is one of the main benefits. Also every project can have its own configuration, for example if you need to run an old PHP or MySql version (which you shouldn't). Best part is, you can run the projects simultaneously.

This topic came up when I searched:

Nice presentation here. As always. I was kind of suprised to see so little feedback or knowledge about DDEV, MAMP, and Laragon. What were they using? Real servers in a local network? Either way... The interview was a great surprise. He seems to be a great guy with lots of knowledge in every space someone could imagine.

Yes! This actually has nothing to do with ProcessWire itself So, regularly, you just want to load the composer dependencies and that's it! But what if you want to test a library you are developing, that has it's own dependencies defined through composer. Ideally too, you want this installed on an existing local project. And you wanna do this with composer itself! Composer has of course has this in mind and it has the symlink flag so that composer knows it should load a local copy where you can have a repository checked out on any branch. { "repositories": [ { "type": "path", "url": "../../packages/*", "options": { "symlink": true } } ] } In my long gone and not missed non-ddev days this worked great with just having my repos checked out in a folder above my project's. I just had to include the local path as repositories, and it symlinked the libraries from the upper packages directory. This wasn't perfect, since when working on the local version, the composer.json and composer.locked got edits that I didn't want in the main branch of the project's repo, so on every change I had to rollback updates in this two files, then install again if I wanted to test "live" versions locally, but more on this later. With ddev this is not so straightforward since the container's volume is isolated from the system. So it threw an error regarding not finding the path to that repo. Of course, there is no "../packages" in the container's volume! Hence, we use the first config to enable a path that is reachable by the composer path configuration within the container. The second config for the .env variable of the path is really unnecessary but thought it would be nice to handle this type of thing in a variable, since each developer might place their repositories in whatever other place within their filesystem. .ddev/docker-compose.composer-packages.yaml: services: web: volumes: - "${COMPOSER_PACKAGE_DIRECTORY}:/packages" .ddev/.env COMPOSER_PACKAGE_DIRECTORY="../packages" And the composer.json configuration for the local repo, see how on this case it is defined from the root, since it's where the volume is mounted from the previous instruction. { "repositories": [ { "type": "path", "url": "/packages/*", "options": { "symlink": true } } ] } And this is is like 80% of of the problem solved! The shell script wrapped in the ddev command is a way to not mess with the regular lockfile which is the one I use to deploy to production. So it creates an "alt" composer.json and lockfile to work in a different composer setup on parallel to the one that is your "production" one.

Woah... (positive and surprised emphasis here) The graph I posted above made it super easy for me to understand differences in loading JS while the one you mentioned... did the absolute opposite. It did almost nothing for me on first look to understand anything. I have to read, have to compare, this, and that... which isn't that of a problem but for a quick first look while trying to understand. NOPE. Sure, the one from your example explains a lot more (which is great), talks about differences, and you learn way more yet ... just looking at it doesn't work for me, what the other one does. Sometimes I just need a good visual hint that explains a more or less complex situation, which mine did (for me at least). That was the reason I posted it here. So we are quite different in consuming such information, and that's super interesting.

We are live and have a very special guest in the video ???

I very much agree it seems complicated! I am very knew to composer packages myself and this is just the first thing I figured out and it felt ddev made it also really easy to make it "ergonomic" for daily use. It's at least a way that makes sense to me haha and I end up with one extra command ( ddev composer-local {$@} ) that just works when I want to work with my local versions and another command to go back on live/latest.

Ok. Now this makes kind of sense to me. It's not about the composer packages in ProcessWire I deal with once in a while in a project, but with those I (never will) develop for later use. This seems to be quite a lot of work for, what I would call it, a simple task like that. But ok, I don't know anything about developing composer packages - that has to be said. Thanks for that detailed answer and background on this. At least I can relax now and know I didn't break a few projects because I used composer packages in a wrong way or something.

Just fan-tastic! You can really see the how instantaneous all the setup can be. Seriously nice extra bonus the interview with Randy! Coincidentally I've been seeing him participate leading the ddev contributor's training sessions. From the few I've watched, it's been really great and interesting.

Cool - interesting insight thanks just to see what others are doing. You could also try the bootstrapping method which I think would allow you write between sites too through the regular PW API. https://processwire.com/docs/front-end/include/

New video about DDEV is out ?

I lived in Nederland many years ago and your portfolio made me home sick. :) Clean site and fantastic photography!

v1.0.2 has been released. A few changes to repeater and repeater matrix treatments, some fixes applied to light mode that helped dark mode a little, and some input contrast improvements. A little bit more consistent, a little easier on the eyes in terms of primary color use.

That's one of the things that "php rockshell pw-setup" does. DDEV is supposed to be used with docker, so you can use it on any OS. You'll get exactly the same environment no matter who is working on the project - that's especially great in teams. Laragon is not by far easier to use but a lot easier to setup. But you only need to setup DDEV once. Then it runs and runs and runs. And with ddev setting up a new project is by far easier then it was with Laragon for me. It's just "ddev config" and you are done. The biggest benefit for me is that you get a real unix dev environment. So if you have some special need for your server (eg creating thumbnails from PDF via poppler-utils you are out of luck with laragon). With DDEV you simply add poppler-utils to the config of the web container and you can develop everything locally and it will work the same on the live server. Also the config of the project can be added to the project's git repo. That means everybody can just do a git pull && ddev start and will have a working version of the project with all the settings and tools needed for it to run. You can't do that with laragon.

Just tried out ddev for the first time and it looks like it is working really well. Thanks @bernhard and others for contributing to this thread. Ddev looks way easier then my previous setup based on homebrew https://getgrav.org/blog/macos-monterey-apache-multiple-php-versions. Here's the steps I had to take to get started with ddev. I'm writing it here so that other people don't have to spend much time with this. `ddev config` - Choose `php` project. Docroot location = `wwwroot` and let it create the folder `git clone --branch dev https://github.com/processwire/processwire.git wwwroot` - Downloads the latest PW dev branch into the 'wwwroot' directory `ddev start` and open the site's url. It will look something like https://pwtest.ddev.site/ Go through Processwire Installer and enter the configurations The Processwire installer might complain about " Unable to determine if Apache mod_rewrite (required by ProcessWire) is installed. On some servers, we may not be able to detect it until your .htaccess file is place. Please click the 'check again' button at the bottom of this screen, if you haven't already." - Just click the "Continue to Next Step" button `ddev describe` - Shows the name, urls, and ports of the running servers Enter the following in the Processwire Installer DB Name = db DB User = db DB Pass = db DB Host = db DB Port = 3306 Character Set = utf8mb4 - if you want emojis? DB Engine = InnoDB Done. Just follow the rest of the prompts to access your site Maybe it could automatically create a site/config-ddev.php that gets automatically included into site/config.php? https://ddev.readthedocs.io/en/stable/users/topics/cms_specific_help/ and https://ddev.readthedocs.io/en/stable/developers/project-types/. Something like: // Automatically generated include for settings managed by ddev. if (file_exists(__DIR__ . '/config-ddev.php') && getenv('IS_DDEV_PROJECT') == 'true') { include __DIR__ . '/config-ddev.php'; } Looks like all of the custom CMS projects are located at https://github.com/drud/ddev/tree/master/pkg/ddevapp After looking at some of the .go files, it looks like it can get a little complex? https://github.com/drud/ddev/blob/master/pkg/ddevapp/drupal.go Oh well. Now it's time to have some fun with ddev and Processwire!

your host seems to be localhost? it should also be "db"

I have created an alias command to get the same settings for all my projects ? alias ddc='ddev config --php-version "8.1" --database "mysql:8.0" --webserver-type "apache-fpm"' So for me its this: ddc --> setup a new ddev project git init --> initialise a new git repo git clone git@github.com:baumrock/RockShell.git cd RockShell php rockshell pw-install I should maybe create an alias for that too ?

What would really be great is a tutorial on how to set up a project in DDEV, something I'm trying to figure out right now ? Edit: Spoke too soon. This is so easy it sounds like a lie. `ddev config` - Choose PHP project `git clone https://github.com/processwire/processwire.git web` - Downloads PW into the 'web' directory `ddev launch` - Go through the config, enter db, db, db, db in the database step Done

@manlio If you want to enhance PW's backend, you're free to use whatever you find useful. Depending on the actual task / use-case, adding Vue.js or a similar SPA framework may be overkill. But if you need to build a fancy dashboard / complicated admin pages, then Vue can perhaps add some nice extras. Care to elaborate on this? You mean "where should these extra frontend assets be stored?" Typically under site/templates. Static assets maybe rather in site/assets/. Make sure to check out @bernhard's epic tutorial about building your own PW module / dashboard. There's a lot of stuff "under the hood" to discover, with functionalities already available out of the box. So if you think about building something along those lines, adding a big JS framework might be overkill, too. Generally speaking it's best to get a solid grasp of vanilla JS. Frameworks tend to make you lazy - e.g. when you're using frameworks to solve problems that vanilla JS can solve just fine by itself. A little recommendation: Here's an excellent tutorial where you learn (among other things): Nuxt Vue.js Dynamic routing (pages, categories) Axios Frontend communicating with a headless CMS (I have re-written the relevant code-bits to work with PW instead of Cockpit) Dynamically setting title tag + meta (stuff that some frontend devs often don't care about - but your customer surely will) Deployment on Netlify (not that I would actually need that - but I guess it's nice to know what the fuss is all about) I skipped several parts... Markdown, Tailwind... and I'm only done with half of it. But it's fun to see how easy it is to have PW generate one or two JSON files, and you're good to go (especially when you have a PW site already with lots of content to play around with). It depends if you really want to learn about all these things ("Developing website is not my primary job"), but it can't hurt.

@microcipcip I am porting this profile to work with GraphQL. I mixed vue, vuex, apollo-boost and graphql and actually, everything is fine. I can query the endpoint, update components, etc. Working now on implementing JWT authentication. As I am quite new in the Vue ecosystem, I was wondering why you suggested vue-supply ?