elabx

Sure mate, come back at it anytime!

The "raw" ProcessWire API, is a bit more verbose but not really a show stopper. Also to be clear with API I mean the whole deal of classes involved in the admin or pages/fields like Field, Fieldtype, Inputfield, InpufieldForm, InputfieldWrapper, etc and hooks involved, not just the global $page, $pages, $input variables. Say with RockMigrations you'd do: $rm->migrate([ 'fields' => [ 'some_fifeld' => [ 'label' => 'Some Fields', 'type' => 'title' ] ]; ]) In "plain" PW API: if($fields->get('some_field')){ $field = new Field(); $field->name = "some_field"; $field->type = "FieldtypeTitle"; $field->label = "Some Field"; $field->save(); } And most of this doesn't really change much with any other field. But indeed since ProFields tend to elaborate on complex things to solve, they might involve a few more steps.

RockMigrations, FormBuilder, ProCache, I think all if not most ProFields. DDEV for local development.

A bit offtopic: Specifically in UIkit I've overcome most some of these issues adding the classes along the attributes of the components, for example if you have a uk-dropdown or uk-drop components, add the uk-drop class too. See how the uk-drop class is the one with the display:none property, hence the issue of seeing it when the js hasn't added the class to the component. .uk-drop { display: none; position: absolute; z-index: 1020; --uk-position-offset: 0px; --uk-position-viewport-offset: 0; box-sizing: border-box; width: 300px; } All assuming you load the CSS before the document.

You can upgrade it, DM Ryan to get an invoice generated.

Being a long time I gave support to this site but last time I knew I got a notifications they closed their shopify store.

Ok so here's what worked for me for now to develop composer packages locally while having them working in a ddev project: Add a volume to the web service on ddev adding file .dev/docker-compose.composer-packages.yaml: services: web: volumes: - "${COMPOSER_PACKAGE_DIRECTORY}:/packages" I've also heard it's advised to add this as a whole other service? Let me know if anyone thinks this is better! You can then define whatever path on your file system in .ddev/.env such as: COMPOSER_PACKAGE_DIRECTORY="../../packages" Now you could just git clone you repos into the path you defined in the variable and "ddev composer install" in case you have the following configuration on your composer.json and it will symlink your libraries instead of { "repositories": [ { "type": "path", "url": "/packages/*", "options": { "symlink": true } } ], } Check the url matches the target the container's path in the volume definition made in the yaml file. I added the additional layer to this proposed by the original article that put me to work, to be able to have my composer.json "clean" and without the local package path definition. I setup the script adviced in the original article: #!/usr/bin/env bash command -v jq >/dev/null 2>&1 || { echo >&2 "jq is required to support local development of composer packages, please install using your OS package manager before continuing"; exit 1; } jq -s ".[0] * .[1]" composer.json composer.local.json > composer.dev.json COMPOSER=composer.dev.json php /usr/local/bin/composer "$@" rm composer.dev.json [ -e "composer.dev.lock" ] && rm composer.dev.lock Save this as .ddev/commands/web/composer-local Create a composer.local.json where you can hold a local configuration that will be merged with composer.json into a temporary composer.dev.json file that will install this merged combination, guarding your composer.local and composer.lock file from being edited. Example I am using as composer.local.json: { "repositories": [ { "type": "path", "url": "/packages/*", "options": { "symlink": true } } ] } If you comment the lines that delete the composer.dev.json you'll see that the property "repositories" value is overwritten by our custom definition. Then run: ddev composer-local install You should see your composer dependencies available as local packages linked to the repository. You can just roll back with the regular composer install: ddev composer install I am still unaware if deleting the composer.dev.json and .lock files are really necessary as it did help me figure out what was going on. Please test if you find this useful and let me know how it goes. Thanks everyone for your thoughts and work put into this thread, I'm really enjoying migrating to ddev!

I wanna put this in a frame ❤️ haha

Hi crew! Does anyone know how to make symlinks work for composer?? Maybe there is an alias path within the ddev container? ? To do something like this: https://medium.com/pvtl/local-composer-package-development-47ac5c0e5bb4 EDIT: Ok, found something! https://carnage.github.io/2019/07/local-development EDIT2: A simplified version? https://adithya.dev/using-docker-for-spatie-laravel-package-development/ more inline with what I had being doing. Haven't tried any of these but will get back when I do.

Not super sure if these have been brought up but I'll lay my experience so far. Problems solved for me and what I liked the most about: It solves sharing the exact environment with other devs within the project itself. I just recently started working with someone who I am also training and to put and example, explaining how to do aliases for php versions in MAMP Pro was a pain, running composer had to be done all with absolute paths for the php version, the composer install in itself too, etc. So even if trivial for an experienced dev, it does introduce friction for less experienced ones. It's all there right after the ddev start, clean and isolated from whatever other project. Of course, maybe there was a cleaner way to do this I never never got to know 'em, don't wanna trash MAMP Pro haha. All the command suite, but specifically love the database import/export ones no need to open phpmyadmin anymore for a simple db import. I really understand the value now of each project running separately. One example, it had happened to me that I was running a database of a few GB in MAMP PROs single installation and it was a pain to turn on and off when I had to update any php.ini configuration since it brought up and down the whole thing, even if I was working on a completely different project than the mentioned big database one. I also didn't love the phpmyadmin screen full of ALL the databases from ALL the projects. It's been really easy to move everything to ddev! It got me into development with Docker and the whole Docker topic in general which wasn't something I was really into since I didn't "need" it. Now I am looking into how to leverage this to deploy productions sites with containers. Maybe this could a whole other topic for another talk? I am trying to move away from panels such as Runcloud/Ploi into a "cloud services" approach and I have the feel that Docker is crucial to this. Pain points: Probably the only pain point I've had is that on a laptop where I might have had docker installed before, I ran the installation commands and got into this issue. But I am not really sure on how to give more input here since I went into "delete all and reinstall mode" and it just worked. Also in my main computer I decided to try Colima and realized that the container volumes were not the same! Maybe this is obvious if you are familiar with Docker. But overall these paint points seem to be very specific, "layer 8 cause" problems haha.

After watching this thread for a long time I finally tested ddev today and wow! I had never setup any environment so fast.

This is the way!

I think you meant to tag @Inxentas ?? I'm a big fan of both of these libraries and I also think they match really well (specifically htmx in this regard) with ProcessWire's existing PHP API, the Inputfield objects, for example.

I think there is no consensus right now about this and indeed pretty much all the asynchronous interactions you see on the backend are powered by jQuery. I'd say go with Vue if that is what you feel most comfortable with.

Support page for module. https://github.com/elabx/FormBuilderProcessorTripleseat

My experiences with terrible performance with MySQL most of the time have to with the indexes being absent or in need of rebuilt.

This sort of thing sometimes happen to me when Tracy Debugger is on, and I get an unexpected warning from some random module that messes up any ajax response by errors appended or prepended to it. Maybe you could take a look in the Network tab to see what you got in the pagination response?

Ok got it!! I understand it all a lot better now, thanks!

With this I mean edits in a CKEditor, or added a repeater item that update some content in the form of a list. Is "npm run build" ran after updating this content? Do this updated trigger a "rebuild workflow" (for example for Vercel) so that the site is completely statically generated?

Very very very interesting!!! @flydev Really appreciate your time put into this answer. The running SSR app generates it's own static stuff if the update in the content requires it, am I assessing this right? I'd love to test an example! Let me know if also I could be of any help.

Don't mind, come back as many times with as many doubts as you have. Yes there are amazing modules put out by the community!

I'd also wonder if any other templating language aside from Blade already works with fragments in a way that it's possible to load only the data in the scope of the fragment.

? Sorry for the lack of clarity! What I meant was, how to setup a development environment using vite, but assuming the development will be along the normal PHP server rendered website, with webserver+php. So, I'd love to know if it's possible to be able to have autorefresh in local development, or auto build of the static assets on watch in this "traditional" setup. I mentioned Wordpress because I feel is common to find already existing examples using Wordpress, which I've found to be a good starting point to adapting it to ProcessWire. Sounds exciting! Your opinion also intrigues me! haha. I do have enjoyed working with more frontend tooling, it used to be a bit more painful. But it "clicked" on me when i built that small js widget I mention. A couple questions: How do you deploy your SSR projects? Do you use something like vercel/netlify/cloudflarepages? I feel this hosting solutions are a nice reason to go SSR? Do you deploy processwire somewhere to have online editors and if so, how do editors handle update/preview? Do you use FormBuilder? And if so, do you use it with this SSR rendered approach? Thanks for this effort and your time answering!

I've used in in a couple projects and it's the "npm build thingy" (sorry i don't even know it's exact classification!) that has given me less pain points. One for a "js widget" built in Svelte (using PW as an endpoint only) and another one for a simple static website with just uikit loaded as dependency (no PW). So both very small projects, but sort of different in their purpose and both experiences were swift to get it to work! So yeah, I do like Vite haha, I feel it's quickly turning into my goto thing as far as frontend tooling goes, which used to be close to non existent. Off-topic request: It'd be rad if you could point to a repo (maybe wordpress example that could be adapted?) with a Vite setup with the regular rendering pipeline of ProcessWire, setting up the proxy for the dev server, whatever other nice thingy could be done, etc.

I don't think there's any shame in mentioning it publicly, or maybe just do it directly in the modules support's thread.