elabx

Not the exact same scenario, but I experienced this using Amazon RDS and even if queries where fast, I did notice the hit of latency. But like 99% of my experience is with mysql hosted on the same machine, so nothing more to add here.

@fruid I think the fields is named "seo_title"?? So it would be $page->seo_title = $page->academicrank.' '.$page->givenname.' '.$page->lastname;

Something I remember trying too, but don't recall if it worked, is adding some Js to the admin to dynamically add the options after an ajax call literally editing the markup. If you're working on recent PW version I'm going it should be straightforward with the new URL hooks. So: Listen to on change event on the theme fiel, call backend with picked value, and do some js work to generate the options for the field and append them to the highlight colors select. Maybe something like this will work better for the scenario where you wan't to use repeaters, although I guess it will involve more work to handle the creation of new repeaters, but I am almost sure there are js events for that. Another idea that I also don't remember if it worked is, using the reload method on the inputfield.js API. So maybe then you just have to listen to the on change on the first field, and trigger reload? Maybe that'll load the field again with the right options?

Not sure sure this can be achieved only with the configuration fields. My first idea is using the Custom PHP code option of the Page field, where you can hook into InputfieldPage::getSelectablePages, then after you have selected the Theme options and saved the page, you can use this hook on the Highlight Color options to get only the colors available through the specific theme previously selected. Check the field's option to view an example. Alas, this might not be the most "intuitive" There is also the Dynamic Selects option which most likely will provide the best interface (without having to do the page save)

Just stumbled into this package and reminded me of this discussion, thought it might be worth dumping it here, maybe the goals it means to solve resonate with the ideas exchanged here: https://fractal.thephpleague.com/

Did you try using transactions ?? That worked for me to save an indefinite number of pages without running out of memory. Thanks for sharing!

Not really, since from the beginning it has been PHP >= 7.0.0

Yes! No updates on code, it really works out of the box in most cases! It grabs the output of your templates and right before rendering it does it all, swaps the script, style tags and there you go, minified and merged. What I do when I have this requirements is to just minify what is required on every page, and whatever libraries that are just loaded to work on a specific context I load them separately, you can add "?NoMinify" to the src url to let know ProCache that a specific file should not be loaded. Comments are removed from HTML for sure! Not sure if from CSS too, I can't remember now. <!-- this might include jquery, htmx or some other library you'll be using everywhere, and are originally placed like this in your template file: <script src="/site/templates/js/jquery.js"> <script src="/site/templates/js/somethingesle.js"> ProCache turns it into the following, right before output: --> <script src="/site/assets/ProCache/minified.pwpc.js"> <!-- that other fancy slideshow library you use in a specific block, this won't get minified/merged in the block above --> <script src="/site/templates/js/slideshow.min.js?NoMinify">

Or InputfieldPageAutocomplete? haha

I think that since $stack is a Page the valid parameter for render() is a field name and not a path. You might be better of doing something like this: <?php namespace ProcessWire; if (wireCount($value)) { echo "<div class='stacks'>"; foreach ($value as $stack) { if (!$stack->isHidden()) { echo wireRenderFile("fields/stacks/{$stack->template}", ['stack' => $stack]); } } echo "</div>"; // stacks } Just adapt the array, passes as a second parameter to wireRenderFile to be named according to the variables in "stack-{$template}.php"

I have used Stripe Checkout and haven't got into this issue ? Are you redirecting to the exact same domain?? Things like this has happened to me when I redirect from Stripe to a different subdomain like "www.domain.com", and session was initially started in "domain.com"

Fastest path to this I think is their Buy Button JS script. Or you could also build something fully customized using the JS Buy SDK.

I don't think there is a plug and play module that enables anything from Shopify. How do you want to make your integration? What do you expect to get from combining both? There's also Padloper 2, an ecommerce module (set of modules?) that has entered Alpha/Early Beta phase!

This would be great!

I think @kongondo gives here a super simple example and even refers to it as trivial, haven't tried anything yet tho:

Basically something like this: image: atlassian/default-image:2 definitions: # Copy files and exclude the ones from .gitignore, # which includes logs and custom overrides out of version control. # Run latest migrations if existing. script: &deploy-script rsync --stats --human-readable --recursive --delete-after --no-perms --no-owner --no-group --exclude-from=$BITBUCKET_CLONE_DIR/.gitignore --exclude="bitbucket-pipelines.yml" $BITBUCKET_CLONE_DIR/* $SERVER_USER@$SERVER_ADDRESS:$APP_PATH; ssh $SERVER_USER@$SERVER_ADDRESS "php $APP_PATH/modules/Migrations/bin/migrate run"; pipelines: branches: main: - step: name: awesomewebsite.com script: - SERVER_USER=$USER - SERVER_ADDRESS=$SERVER - APP_PATH=$PATH - *deploy-script dev: - step: name: dev.awesomewebsite.com script: - SERVER_USER=$DEV_USER - SERVER_ADDRESS=$DEV_SERVER - APP_PATH=$DEV_PATH - *deploy-script So it's like a tad bit more fancy FTP upload lol

Well in this scenario I was talking about a particular project that is more "app like". But the rest of sites I manage, which might have specific features regarding template/fields, different templates that are for one specific website/design, I handle them the same way, repo and deployment through pipelines. I'd love to hear about what other things you've tried if you'd be keen on sharing. I've seen some folks move to Statamic/Kirby for this purpose. Thinking about this I've thought a "migration recorder" built on field save hooks, would be neat. Like, you're doing your work on PW thinking about the awesome features you wanna build, building repeaters/matrix, changing file widths, show conditions, all those things we love. Then you go into Setup > Migrations and you find all the work you just did on your repeater field recorded. Just a thought for one part of the whole problem. EDIT: I just read about the YAML thing Craft does, thanks for sharing! ?

Give a look at this blog post: https://processwire.com/blog/posts/pw-3.0.153/

Hey @Moritz! I use RockMigrations to handle most of the API related stuff along the initial Migrations module, which has a CLI interface letting me run pending migrations per site and keeps the track of it. The sites all share the same features and templates, nothing can be added as a "site specific feature" that involves a "custom pw stuff" in the database, it religiously needs to be in sync. I use bitbucket pipelines for deployments, and it's a very simple script involving rsync and running the Migrations CLI. I do write everything that involves a "new feature" regarding fields on a page, repeater matrix, etc. I'd say once you got it figured out, most of the time i'm copy pasting between migrations and adapting. I'd love to get in sync with some sort of automated testing (end to end with cypress?), but right now it just involves manually testing, and deploying to a few sites to test, fix otherwise and deploy again. I guess this is more of a management issue?? Maybe I am not understanding your full perspective here. No db dumps becase as you mention, it will mess up content. HannahCodes I migrate using the text version export of the hannahcode haha Module updates I guess just upgrading the files?? Haven't got into a deeper issue where something breaks while doing these. I think, up to know, I have just installed new modules. I keep processwire install outside of this equation, I am not sure if this was a wise decision, but it is like that lol One thing that is super important that I haven't though very well is rollbacks. Right now I basically would just run another migration on top, chekout/cherrypick from earlier branch or sth. Though haven't had enough time on this setup to mess up like this and need a rollback or where just doing a migration on top wouldn't work.

I've thought of this a bunch of times! Common settings for the repeater types. Some I normally use are visibility settings, and sometimes dates for ranges to enable/disable.

Something else I've done is dynamically manage the options available for a page reference field depending on where it is in the page tree through a few hooks. So, say each product category has as children two more "parent pages", one for the products, and one for the specific categories of that product page. I won't go into much detail right now as I don't even know if if suits your case.

I'd approach this with either Page fields. Would it matter if the available sizes available for selection in appear on every product-category??

Check the classes that are rendered within the body tag, you should see useful classes there to override css per-role. If you mean tabs/fields within the edit pages screen, there is a lot that can be made through roles and field permissions. https://processwire.com/blog/posts/field-permissions-overrides-and-more-2.6.2/#granular-access-control-with-field-level-permissions This post is old but I bet (without guarantee) that it most likely remains the same or very similar. This Dashboard is super configurable and I bet you can simply wrap the configuration of the panels into some switch/if statements to deliver configurations per role/user.

Not sure if you read my last post and why I asked what I asked but nontheless I think you could try the following code on ready.php. Have in mind, the following function declared in the saved() hook executes after the page is saved, which would be my first approach in getting the gecoded location without doing all the pages in one request . So this approach sort of "throttles" geocoding the address, doing it only when the user adds the address. $wire->addHookAfter('Pages::saved', function(HookEvent $event) { $page = $event->arguments(0); // Skip if not the template we are interested in.. if($page->template != 'customer_project') return; $geo = new \OpenCage\Geocoder\Geocoder('API-KEY'); //This is the field that contains the address in the pages with customer_project template $address = $page->address_field; if ($page->customer_project_address === 1 && $address){ // I guess the first param is the actual address? $address assigned above? $result = $geo->geocode("Another location", ['language' => 'Sweden', 'countrycode' => '+46']); $first = $result['results'][0]; $coordinates = $first['geometry']['lat'] . ',' . $first['geometry']['lng']; //here the field gets saved, have in mind that this is different than saving //the whole page, which would get is into an infinite loop in this scenario $page->setAndSave('my_location_field', $coordinates); } });

Would it work if after one of the following events: User visits page (literally opens up the browser in the page) Page save (whoever saves the address, hits Save in the admin, or the page is saved through the api) The location lat, lng would get added and saved to the page's field through the API?