rastographics

UPDATE 2: I was able to get the bootstrap migration to install without problems, after deleting the assets/cache/dbmigrations folder (I didn't know about that before) and also using version 2.0.23 of the module.

Update: I did a fresh install of Processwire (3.0.242) and I get the same problem with failure to install bootstrap migration. What I've noticed with their problem is that that the dbMigrate fields and templates are present. But the bootstrap migration will never indicate that it is fully installed. If I lock the bootstrap migration and try to add new migration on local machine, I can, but when I push the new migration to production, it says "already installed" but nothing changes, because no migration items appear under the migration for some reason. I think the reason is related to the fact that the bootstrap is not getting installed completely but I don't know enough about the raw database structure and how this module works under the hood to know what is going on. The other site that I have dbMigrate working perfectly, is using 2.0.23. Maybe a bug introduced from 2.0.23 to 2.0.24?

This is the result if I un-check auto-install bootrap and try to install it manually:

Thank you, i have been using the latest version 2.0.24. I tried several times also completly uninstalling and reinstalling. I previewed the changes for the bootstrap migration and this is the output: Differences between current and install data Key current install pages->new->/admin/dbmigrations/ > title (No Value) DB Migrations pages->new->/admin/dbcomparisons/ > title (No Value) DB Comparisons Differences in migration definition that do not affect data.json files (but do affect migration.json): pages->changed->/admin/dbmigrations/bootstrap/ > title (No Value) bootstrap > dbMigrateLogChanges (No Value) 2 > dbMigrateSummary (No Value) This is the initial migration to install all the required fields, templates and pages for the module to work. It is bootstrapped, on first running the ProcessDbMigrate module, from the json files. > dbMigrateAdditionalDetails (No Value) If you want to amend this bootstrap, for example to implement changes to the layout of the DbMigration template, then you may need to first make it 'exportable' in the source (development) environment by removing the meta('installable') from this page. > dbMigrateItem (No Value) [ { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateType", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateAction", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateName", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateOldName", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 2, "dbMigrateAction": 1, "dbMigrateName": "repeater_dbMigrateItem", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateItem", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 2, "dbMigrateAction": 1, "dbMigrateName": "repeater_dbMigrateComparisonItem", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateComparisonItem", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateSummary", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateAdditionalDetails", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateRestrictFields", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 2, "dbMigrateAction": 1, "dbMigrateName": "repeater_dbMigrateSnippets", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateSnippets", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateRuntimeControl", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateRuntimeAction", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateRuntimeReady", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateLogChanges", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateTrackingScope", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateFieldTracking", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateTemplateTracking", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigratePageTracking", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 1, "dbMigrateAction": 1, "dbMigrateName": "dbMigrateTrackingScope_END", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 2, "dbMigrateAction": 1, "dbMigrateName": "DbMigration", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 2, "dbMigrateAction": 1, "dbMigrateName": "DbComparison", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 2, "dbMigrateAction": 1, "dbMigrateName": "DbMigrations", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 3, "dbMigrateAction": 1, "dbMigrateName": "/admin/dbmigrations/", "dbMigrateOldName": "" } }, { "template": "repeater_dbMigrateItem", "data": { "dbMigrateType": 3, "dbMigrateAction": 1, "dbMigrateName": "/admin/dbcomparisons/", "dbMigrateOldName": "" } } ]

@MarkE Love this module, thank you for sharing it. My brain works better with the way this module works than other migration modules I've tried. I have it setup and working perfectly in 1 installation. Using it for a second site, and keep running into an issue after installation. Immediately after installing in Dev site on my local machine, the page response time goes from <100ms to 1,000-1,500ms, and I think the reason is that on every single page load, the message is at the top: Bootstrap not fully installed. Attempting to reinstall... And also a list of 70 or so pages that have been modified or changed. This happens on every page load, front-end, back-end, doesn't matter. I think because the bootstrap migration is not installing, it is attempting on every page load, which slows down the site. I did not run into this before on my other site. How can I troubleshoot to figure out what is keeping the bootstrap from completing?

Very cool Ryan. Thank you for this, I never used functional fields before but they sound perfect for a use case I have right now.

For handling datetime in Processwire, I've come to realize that the best way for me to avoid the most headache is leave EVERYTHING in UTC...the $config file, the ddev settings, etc. Then whenever I need to display times on the front end, I use a helper function I created that formats time in the Timezone of my choosing, at display time. With this method, the production server timezone or my dev environment timezone never matters. The added benefit is that you can have users save a timezone to their profile and then display times in their timezone. Any other way of dealing with timezone besides saving UTC to database has always created a mess for me later down the road. function UtcToCst($timestamp) { if(!$timestamp) return; return (new \DateTime("@" . $timestamp))->setTimezone(new \DateTimeZone("America/Chicago")); //Or use a timezone saved on your $user template. }

Thank you for the site profile and especially the blog post and extensive comments throughout the code. It's extremely helpful for overall architecture examples, which is something hard to find by just reading documentation or searching forum, because recommended practices have changed over the years. Especially love learning how you do things in the admin side for customizing the page edit screens, etc.

Solved w/ Hacky Workaround: By adding a line of code to InputfieldImage.js, I'm able to now specify a url to POST to when using AJAX upload for InputfieldImage. //LINE 1635 of InputfieldImage.js function initHTML5Item($this, i) { //THIS CODE IS UNMODIFIED >>> var $form = $this.parents('form'); var $repeaterItem = $this.closest('.InputfieldRepeaterItem'); var postUrl = $repeaterItem.length ? $repeaterItem.attr('data-editUrl') : $form.attr('action'); // <<<<<< THIS CODE IS UNMODIFIED /* To get InputfieldImage to work on a page besides the ProcessEditPage We need to change the POST url for ajax uploading of images, to point to the EditUrl of the page that contains the image field. We can set the custom action url on the form html element. But we need to grab that value here if it exists. */ //THIS LINE WAS ADDED BY JOEL TO MAKE INPUTFIELDIMAGE WORK ON OTHER PAGES.... if($form.attr("ajax_action")) postUrl = $form.attr("ajax_action"); //THIS CODE IS UNMODIFIED >>> postUrl += (postUrl.indexOf('?') > -1 ? '&' : '?') + 'InputfieldFileAjax=1'; And in my custom admin module, I add this attribute to the form that contains the image field... /* AJAX Image uploads. Set a custom ajax POST url here that will be used in the core InputfieldImage.js file to have the correct upload url for ajax images on the InputfieldImages. */ $form->attr("ajax_action",$mypage->editUrl); Now it works flawlessly! (Don't forget to add "<div style='display:none' id='PageIDIndicator'>$mypage->id</div>" someone on the page too! as mentioned in previous post)

I create a simple Process module that retrieves specific pages and displays them one at a time on an "Edit" page. The edit page contains a form like so: $form = modules()->get('InputfieldForm'); $form->add($myPageToEdit->getInputfield('my_image_field') $form->add($aRelatedPage->getInputfield('my_text_field') I also add a submit button and some other fields for editing that are not relevant. `my_image_field` is an image field. When this custom edit page is displayed (in the admin, a url like examplesite.com/admin/my-module/edit?id=2494), the form shows up fine. If the image field is populated, then the existing image displays correctly. Using the form to edit the text fields (or even repeater fields) works great. But the image field on this custom module has broken behavior. First of all the Ajax Upload functionality is disabled. I figured out it is because of this code in InputfieldImage.js: /** * Whether or not AJAX drag/drop upload is allowed? * * @returns bool */ function useAjaxUpload() { var isFileReaderSupport = window.File && window.FileList && window.FileReader; var isAjaxUpload = $('.InputfieldAllowAjaxUpload').length > 0; var isPageIDIndicator = $("#PageIDIndicator").length > 0; //THIS ELEMENT DOES NOT EXIST ON MY MODULE'S PAGE SO AJAX UPLOAD GETS DISABLED??! return (isFileReaderSupport && (isPageIDIndicator || isAjaxUpload)); } Because it is looking for #PageIDIndicator, which doesn't exist, then ajax gets disabled? So I have to work around by adding that element to my page like we find in ProcessPageEdit.module (Line 640) $out .= "<div id='PageIDIndicator' class=''>{$this->page->id}</div>"; So on my module I add <div id='PageIDIndicator'>3423</div> where 3423 equals the page id. NOW Ajax Upload is enabled. But it is very broken. Because the functionality to process the ajax upload is in ProcessPageEdit only, and it is expecting a JSON response...but the form needs to postback to my custom module edit page, which doesn't know how to respond to AJAX and specifically process the InputfieldImage upload. So it seems like the AJAX upload functionality is baked into ProcessPageEdit, and so the InputImageField was not designed to be used anywhere in the admin except on ProcessPageEdit? Something tells me there has to be a way to configure the InputImageField in my form to work in a custom module for Ajax uploads? By the way, Non-ajax uploads work with no problem from my custom module. But they are very unintuitive and limited to one photo at a time. Deletes also work.

Yes! And reading that while being a little frustrated with the way I'm currently doing htmx and processwire

Thanks @cwsoft and @zoeck. I've used custom page classes for a while but I don't think to full potential so I'm sure these resources will get me to the next level of what is possible. My reason for coming to this thread is I'm trying to have a more elegant way of using htmx by using "partials" on the php side, and I read that latte will let me break the html up into partials better than the regular php templates. Excited to hopefully use latte to make the htmx experience better. And just overall structure my processwire projects better.

I want to do this to my projects too. What resources did you use to learn how to do this @cwsoft? Or is any of your code shareable? Thank you!

$tomorrow1AM = strtotime("tomorrow 1:00"); echo cache()->renderFile("chunks/home/birthday.php", $tomorrow1AM); This code works fine if I use a WireCache constant for the expire parameter. But if I use a timestamp, as shown above, the cache doesn't work. The cached does get "created" (verified by looking in TracyDebugger) with an expire time of 1am the next day. However, the page is still loading 1700 pages of content, and taking 800ms to execute, as opposed to 53 pages of content and 90ms to execute when the cache is correctly getting used. So it seems that $cache->renderFile is saving the cache, but not hitting it on future loads in my case. Do you have any insight? Any other information I need to share?

For now I'm doing this on line 271 of AppApi/classes/Auth.php . But I have to be careful when updating the module now. /* ADDED TO GIVE JWT ACCESS TOKEN A DIFFERENT SESSION LENGTH THAN REGULAR SITE LOGINS */ $config = $this->wire('config'); $expireSeconds = $config->sessionExpireSeconds; if(isset($config->appApiSessionExpireSeconds)){ $expireSeconds = $config->appApiSessionExpireSeconds; } $apptoken->setExpirationTime(time() + $expireSeconds);