psy

@Steve_Stifler WOW! No wonder you want to move it from WordPress. Have you checked out the code? Yep, got the idea after the first page, ie: Clicking on a building is cute but terrible for accessibility and really not intuitive Yawned waiting for all the javascript files to load It's not responsive - just doesn't work on mobile size devices What looked like links - Less time, Less money, etc weren't On the plus side, love the home page image and 'get' what you're aiming for. All WP is doing is injecting javascript & code to render stuff on the home page. Your challenge is to figure out what script is doing what, then include the minimum to achieve same in the ProcessWire template. Happy to help you with that - DM me if you're interested in collaborating on this project. As for my profile pic, thank you for the compliment. No photoshopping either. It's amazing what a truckload of spack filler, good lighting and an amazing photographer can do

@dragan spoke with Alex @ PushAlert and the short answer is it has to be in the root. Long answer is that there is alternate, unpublished code that allows integration in sub-directories. Alex will send me the code to review. Will keep you posted Update Using PushAlert from PW site installed in a subdirectory is not difficult. It will require an additional field on the module config page and is on the roadmap for the next release.

Hi @Steve_Stifler can you give the current URL so we can understand better what you mean? Please DM me if you dont want to publish it here.

Oh dear, this wasn't happening before but have been able to reproduce the issue. Will let you know when the fix is available FIXED and updated in gitHub: In PushAlert.module, change lines 160 and 161 to: $paUrl = $widget->pa_message_url; if (empty($paUrl) || stripos($paUrl, '/page/edit/') !== false) { $paUrl= substr($this->wire('config')->urls->httpRoot, 0, -1) . $page->path; }

Good pick up @dragan Fixed. Had H:m:s instead of H:i:s in line 135 of InputfieldPushAlert.module.php

Hi @dragan Thanks for the feedback. I believe PushAlert only accepts the root domain. I will ask PushAlert support for clarification. The icon is always visible. After you've subscribed, it changes to an unsubscribe button. Not sure but may be related to the date issue? No timezones are hardcoded. It is a standard PW Date Time picker inputfield. It gets converted to a timestamp for submission to PushAlert and saved in the field json data. It gets reconverted to a string when the page edit is redisplayed by the date field. The URL submitted to PushAlert should be the frontend URL (always has been in my testing?), called in the code with $page->httpUrl. Are you using ProCache and stripping optional tags? The script needs the closing </head> tag. I'll work on an alternative way to manually call the script in the template. When you use only the PushAlert code, you miss the custom onSuccess callback function. This function posts back to PW to save the subscriber ID and logged-in user ID in the database. <script> function callbackOnSuccess(result) { let topw = {}; topw.subscriber_id = result.subscriber_id; topw.alreadySubscribed = result.alreadySubscribed; var json = JSON.stringify(topw); return fetch("https://mywebsite.com/pushalert-endpoint/", { method: "POST", headers: { "Content-Type": "application/json", }, body: json }); } </script> The only time, very early on in the development cycle, I got double notifications was when I had both sw.js and the PWABuilder service worker installed and they clashed horribly. The existing service worker called the page as did PW for faster load times and so the notification went twice. Are you using multi-language? Maybe that's having an effect?

This module enables you to send push notifications and receive information about sent notifications on your HTTPS ProcessWire website. It enables you to: Create a field of type FieldtypePushAlert that you can add to a page template. This is a multi-input field widget that enables you to send notifications from your page in the admin Page Edit and monitor statistics - Attempted, Delivered, Clicked, etc Send notifications from a page template directly using the API, eg to PW users who have a specific role and have subscribed to notifications Capture subscriptions on your website front end All kudos to the great support team at PushAlert and to all the ProcessWire developers who've helped me with this project. Download from the Modules directory at: https://modules.processwire.com/modules/push-alert/ or from GitHub at: https://github.com/clipmagic/PushAlert Full instructions for use are in the module README.md file. Enjoy!

Hi @Steve_Stifler and welcome to ProcessWire Forget the WP model of themes etc that force you into their on-screen boxes. With ProcessWire you have complete control over what goes where & how on the frontend. You design your frontend layout and retrieve the data you need to populate the page in the templates

Quick update Please (whatever deity you choose), I'm close to publishing an alpha version. The PushAlert API is easy. It's the PW integration that challenged me. If you only ever want to capture subscriptions to PushAlert and send notifications carte-blanche via a PW template without capturing stats, and/or sending advanced options, eg to a specific user instead of everybody, the instructions in the PushAlert docs will get you going. This module is more than just a wrapper... more soon including the readme.md (why does that always come last?) Anyone interested in being a guinea pig tester?

Usual way is something like this in your module (adjust to suit your needs): /** * @return array */ static public function getDefaultConfig() { return array( "my-module-config-1" => "", "my-module-config-2" => "", "my-module-config-3" => "my default setting for this config field", ); } /** * Populate default configuration (will be overwritten after constructor with user's own configuration) * */ public function ___construct() { foreach(self::getDefaultConfig() as $key => $value) { $this->$key = $value; } } /** * @param array $data * @return InputfieldWrapper */ public function getModuleConfigInputfields(array $data) { $inputfields = new InputfieldWrapper(); $defaults = self::getDefaultConfig(); $data = array_merge($defaults, $data); $f = $this->modules->get('InputfieldText'); $f->name = 'my-module-config-1'; $f->label = __('MyModule key 1'); $f->value = $data['my-module-config-1']; $f->collapsed = 5 ; // collapsedPopulated $inputfields->add($f); $f = $this->modules->get('InputfieldText'); $f->name = 'my-module-config-2'; $f->label = __('MyModule Config key 2'); $f->collapsed = 5 ; // collapsedPopulated $f->value = $data['my-module-config-2']; $inputfields->add($f); $f = $this->modules->get('InputfieldText'); $f->name = 'my-module-config-3'; $f->label = __('MyModule config key 3'); $f->collapsed = 5 ; // collapsedPopulated $f->value = $data['my-module-config-3']; $inputfields->add($f); return $inputfields; } Then you can call it in your template like: <?php $myModule = $modules->get('MyModule'); ?> <p><?=$myModule->my-module-config-1?></p> Best way to learn is to look into other popular PW custom modules

Thanks for the suggestions. I ended up putting the conditional further down the food chain for now. It works and with page caching, shouldn't affect the front end page render speed. Maybe in a later release I'll fine tune it a bit more

More... $page->template == 'admin' Works BUT it interferes with the receipt of the WireHttp call to get the json result. It always comes back as null. Works fine when I remove this conditional from the hook, but then the front end falls over. I supposed I could put a conditional further down to see if the http result is valid but am concerned that will dramatically slow down front end page load. The test could only be done after the GET call and a bunch of database hokey pokey. Would be much more efficient to have it at the start of the hook - if it's the front end, return now; if it's admin, process the GET call etc

@matjazp Thanks, tried both and they didn't work. $page->template == 'admin' meant it affected the page list $page->process is 'Process Template' for both front and back end, including page list - maybe due to hook method Page::loaded

I'm well into developing a module that has both front and admin features so don't want to flag the module as 'admin only'. One hook has very specific requirements: ONLY applicable in admin ONLY applicable if in page edit on a page that will have front end output (not a custom admin page) ONLY applicable if the page has a particular Fieldtype which is a custom field type specific to this module suite I've got 2 & 3 down but am stuck trying to figure out 1 despite trying lots of things. When viewing the page on the front end, the hook activates and crashes the page. public function ready() { $this->addHookAfter('Page::loaded', $this, 'hookResultJson'); } public function hookResultJson (HookEvent $event) { $page = $event->object; // Only applicable in admin area in page edit mode // STUCK ON THIS ONE ????? // Confirm the page has a FieldtypeMyCustom field $fields = $this->wire('fields'); $paFields = $fields->find('type=FieldtypeMyCustom'); if (!$paFields->count) return; $widgetFld = ''; foreach ($paFields as $item) { if ($page->hasField($item->name)) { $widgetFld = $fields->get("name=".$item->name); break; } } // No field of FieldtypeMyCustom on the page/template if (empty($widgetFld)) { return; }; // We are now in admin edit of a page that has a field of type FieldtypeMyCustom // ... } Any suggestions for the 'admin only page edit' conditional statement? TIA psy

Agree with @wbmnfktr Have always used subdomains on my development host and never encountered this issue