Leaderboard

Yes, and I misread your post, I didn’t paid attention that the site is served from MAMP through prepos proxy. And as you already spot, they are transformed in your bundle source. Keep in mind that all process calls are Node.js things and aren’t available in the browser. Anyway, on the example of Alchemy, the api key is made for you, what I mean is, the front app make a request to ProcessWire endpoint, then the needed requests are made from ProcessWire to alchemy endpoint using your api key stored on server side, eg. in template or module, db, .env file/process, then Alchemy answer your server, and finally, ProcessWire send back the response to the front app. It seem you got the idea. What is complicated on your side, if I can help? If is just to test and see external services like alchemy from local, just do not scratch your head to much, and use them as they are, included in the bundle. Using env variable on this case make things easier than going into the source code to change them.

thanks @flydev this helps. I haven't got php dotenv to work yet. I realize my API secrets were getting bundled into PrePros's JS dist bundle. I've been looking for solutions, even thought that maybe I could store it in a PW page's field, but I have hit a block when thinking of ways I'd be able to access that from within my javascript src code. Looks like with Vercel, Netlify, et al the ENV variables can be stored in their dashboard. Otherwise it looks like a proxy server for API keys on the backend is the way to go, but a little complicated for my situation.

Hi again, Many thanks for your hints, with your help I think I have tracked down the original issue. I copied in a new version of the Procache directives tot he .htaccess file recently and that seems to be the issue. I may have copied them incorrectly so I'm not saying it's the code but reversing to an older version of the .htaccess resolved the Lister issue. The login issue 'Unrecognised path' still remains though. Thanks for your help and the hint in the .htaccess date change!

@protro nice tool, I think I am going to build something similar but based with vite/rollup. About your issue, as you pointed it, your are serving your website from MAMP server, then the env will not be available on built app when served by MAMP and you will need to use a solution like php dotenv, and I saw you already read the thread about dotenv then I assume you got it working ? It's also worth noting that by using prepros you are bundling your app with webpack and not vite or rollup, keep in mind that when you will head to js libs documentation or when trying to find what's is not working. Under the hood, there is the stack list: Webpack 5.86.0 Babel 7.22.5 Autoprefixer 10.4.14 Node Sass 9.0.0 PostCSS 8.4.24 PostCSS Preset 8.4.2 Dart Sass 1.63.3 Tailwindcss 3.3.2 Terser 5.17.7 Yes. Or to be more precise, what we can call Entry points. It contain the entry point of your app and the vendors. For more information about the splitting process head to webpack doc.

Same for me here, PHP 8 is ok. Also Snipcart v3 only. Thanks for updating the module!

After 4 years, it should be okay in my opinion. All my E-Commerce are on 8.x. I personal see no reason for 7.4. Since SnipCart self is again awake in developing, maybe a major version bump on the module side for a chance to cut old branches?

That's definitely strange. No recent modification date on index or htaccess (modrewrite) files for the site? It's strange that only lister seems to be affected. The (query string in the) full path when you login is different than the full path when you load the page tree. There might be something strange there too, but it's sometimes easier to focus on one thing than multiple. I am honestly not entirely sure what to recommend at this point, based on the provided symptoms. Have you reached out to the server maintainers to see if anything had recently been changed? EDIT: If your local version works fine, maybe download a backup of the live site and compare the files (diff), or just run it locally and see if it's reproducible on your own development server. If it is, it's probably easier to diagnose there anyway.

I'm guessing this is the intended behavior, so this might be a feature request more than a bug. I ran into an issue with a module where there was an asmselect inputfield that I was trying to add additional options to and they kept reverting. What was odd to me was that I don't believe any migrations were actually running, but the options array that I had included in the installModule call kept returning and overwriting my changes. The watched file containing the module installation calls had not triggered as far as I can see in the logs, but the options array values kept overriding my attempts to expand the selections. (It says the file was skipped). Is there a way to set the options for a module on installation so that you can choose between setting a locked-in configuration or just setting default/initial settings for the module? EDIT - I realized that the reason the installModule was installing the options repeatedly was because I placed the install in the init() for a custom page class. I should move it to the migrate() at least or perhaps put additional checks in place to determine if it is necessary to populate an options array.

With the next SnipWire release I plan to support only V3 of the Snipcart engine. Supporting both versions would be too much effort. How do you think about this?

I found the solution with wireLangReplacements() function. /** * Replace "Missing required value" text ONLY on frontend * */ if($page->template->name != "admin") { wireLangReplacements([ 'Missing required value' => 'My replacement value', ]); }

Same here. I've been tinkering with SSE on and off, and that one-liner made the crucial difference.

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 have had this problem sometimes on a windows machine. It seems to happen for no apparent reason and then go away again. I know that’s not very helpful. Intermittent bugs are the hardest to track down. However, it is helpful to know you are not alone! Next time it happens, I’ll pay more attention to what might have caused it.

Can you explain what this feature does?

Have you tried with a clean default PW installation with a default template and just Tracy installed? If that works try to install your two rock modules in two steps and check if console lags still occur. Thats what I would try to narrow down the possible error sources. If you can find a reproducible setup it‘s easier to spot the error for others like Adrian too.

Not sure if I'll post every issue here, but at least here's the first one ? --- Hey there, RockStar developers! ? What's new in the Rock Universe? ? baumrock/AdminStyleRock v1.3.0 Make your ProcessWire backend truly yours with the latest AdminStyleRock update! Version 1.3.0 brings a super cool feature that allows you to effortlessly set a custom logo in the ProcessWire backend. Your admin experience just got a whole lot snazzier! ? ? baumrock/RockFrontend v3.3.0 Get ready for greatness with RockFrontend v3.3.0! We've introduced exciting new features, including static site rendering and a nifty view-folder feature. The top bar's hidden style has been polished for that sleek look. While we're working on documenting these gems, be sure to explore and experiment with these additions! ? ? baumrock/RockShell v2.1.0 Our new db:download command streamlines database management even more. And here's a treat: an alias for your laptop lets you simply call "rockshell db:pull staging." Say goodbye to the lengthy commands and hello to efficiency! ?️ ?️ baumrock/RockMigrations v3.29.0 Prepare to be wowed by RockMigrations v3.29.0! This version brings a fresh approach to shipping your modules with custom page classes. Plus, our new path helper methods ensure your paths are on point, with normalized separators and no more pesky multiple slashes. Another really helpful feature was added to RockMigrations this month, but then removed because it's now part of TracyDebugger itself! Say hello to the "Redirect Info" section in the "Request Info" panel! Have you ever been redirected by something and didn't know why? That belongs to the past as you can now clearly see that the redirect was triggered by line 3 in /site/templates/home.php  ? Sneak Peek: Exciting Commercial Modules We've got some fantastic updates brewing for our commercial modules, slated for release soon. Brace yourselves for RockCommerce, the power behind the shop on baumrock.com, where you'll find our incredible modules up for grabs. And speaking of modules, RockPdf has been making monumental strides. It's now responsible for crafting the invoices that accompany every order. ?️ ? Stay Connected: As we rock and roll into the future of development, there's plenty more where this came from. Stay tuned for more exciting updates, innovative features, and game-changing modules that will take your projects to new heights. Thank you for being part of our developer community. Your passion and feedback keep us strumming along. Until next month, keep coding and keep rocking on! ?? Keep rocking, Bernhard

Lots of great stuff in RockMigrations v3.29.0 Sorry for the ugly background but otherwise the links don't work!

Hi all, I've released 0.9.0, which brings the minimum PHP version to 7.4, adds support for PHP 8, and adds support for Composer 2. Also released 0.9.1 which handles @gebeer's suggestion (thanks!). Note, however, that I've published these versions on a hunch that they will be ok – I do not have a PW setup for testing. If something is broken, let me know and I'll fix it.