psy
-
Posts
636 -
Joined
-
Last visited
-
Days Won
8
Everything posted by psy
-
@dab, yes, the PushAlert support team are almost as helpful as the PW devs here ? DON'T use the PushAlert sw.js file. It's the vanilla version and doesn't include the PW custom code to save subscriber ID's with PW user ID's. The module will automatically add sw.js + the custom function to the <head> for you. See my post to @dragan about this above. Also see the IMPORTANT section of the README about manifest.json. If you're site already has one, just add the gcm_sender_id code line.
-
@dab Great it's now working for you. All credit to flydev for the fix ? The reporting of "Attempted" rather than "Delivered" is a question for PushAlert support. Once PW sends the notification, it hands over to PushAlert and then catches the response to report the status.
-
@flydev grateful for your patience with me on resolving this issue. Fixed in gitHub Working code is: $http->setHeader("Authorization", "api_key=". $this->api_key); Also updated the _getHttp function with same fix in gitHub
- 23 replies
-
- 2
-
-
- alerts
- notifications
- (and 1 more)
-
@flydev Thanks again for the detailed feedback. My development site runs PW 3.0.124 so I don't understand why the behaviour would be different? C'est la vie. In version 3.0.124, Ryan introduced support for cURL in WireHttp https://processwire.com/blog/posts/pw-3.0.124-and-new-site/#wirehttp-updated-with-curl-support In the PushAlert.module I tried to take advantage of this new feature, from Line 439: // Prepare and send the request $slug = "send"; if($this->wire('config')->version('3.0.124')) { // ProcessWire version is 3.0.124 or newer $result = $this->_sendHttp($slug, $options); } else { $result = $this->_sendCurl($slug, $options); } return $result; } /** * @param $slug * @param $options * @return mixed */ private function _sendHttp ($slug, $options) { $http = new WireHttp(); $headers = Array(); $headers[] = "Authorization: api_key=". $this->api_key; $http->setHeaders( $headers); $result = $http->send($this->api_url . $slug, $options); return $result; } /** * @param $slug * @param $options * @return bool|string */ private function _sendCurl ($slug, $options) { $headers = Array(); $headers[] = "Authorization: api_key=" . $this->api_key; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $this->api_url . $slug); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($options)); curl_setopt($ch, CURLOPT_HTTPHEADER, $headers); $result = curl_exec($ch); return $result; } Because I cannot recreate the issue, would you please try commenting out lines 458, 459 & 460 and replacing them with: // $headers = Array(); // $headers[] = "Authorization: api_key=". $this->api_key; // $http->setHeaders( $headers); $http->setHeader("Authorization: api_key=". $this->api_key); and let me know if this resolves the issue. More: I used Array() in WireHttp to keep it consistent with the cURL method. Happy to change in the module _sendHttp method if WireHttp headers array works differently. Still wondering why it worked on my PW 3.0.124 and not for you...
- 23 replies
-
- 1
-
-
- alerts
- notifications
- (and 1 more)
-
@flydev Great feedback and excellent suggestion. On the list for the next release ?
- 23 replies
-
- 1
-
-
- alerts
- notifications
- (and 1 more)
-
@dab Thank you ☺️ The field creation bit is pure PW, not PushAlert related at all so not sure why this occurred but good to know about uppercase/lowercase in field names. The deletion of the pushalert_endpoint.php template is also pure PW/PHP as per the docs: https://processwire.com/api/ref/wire-file-tools/unlink/ // Delete the endpoint template file - should never be customised $templatePath = $this->wire('config')->paths->templates . "pushalert_endpoint.php"; if (is_file($templatePath)) $this->wire('files')->unlink($templatePath); Could it be a permissions error?
-
@dab Thanks for the feedback. I'll investigate. I spent more time on the install/uninstall process than the actual integration but that's development for you. I tested on PW 3.0.74+ and PHP 7.0. Not sure if the fact you're using PHP 5.6.40 is the cause. From your post it seems that the database table field_PushAlert was not found. Is your field name PushAlert? Maybe there is a problem with capital letters for field names in the DB? Your second issue is a puzzle too. The only place in the module where unlink is used is in __uninstall to remove the push_alert_endpoint.php template. Was this created?
-
How do we run a selector and statement saved as a variable?
psy replied to Zahari M.'s topic in API & Templates
Hi @Zahari M. well said! Hello and welcome ? -
How do we run a selector and statement saved as a variable?
psy replied to Zahari M.'s topic in API & Templates
@Zahari M. @LostKobrakai is very knowledgeable about ProcessWire and, I've found, always willing to help. Maybe it's a language thing but please do not assume all ProcessWire devs are 'gents' -
Are ready.php hooks/addHookMethods called outside their use?
psy replied to a-ok's topic in General Support
There's no 'escape clause' in your code so it will be triggered on every page view, eg: wire()->addHookMethod('Page::ipapiGetUserLocation', function($event) use($ipapiHttp, $ipapiAPIKey) { $page = $event->object; if ($page->template != 'templatename') return; // your code here ... } -
The fact that the data is being stored in the database as json is good. On retrieval you need to explicitly tell PW what/where to put the data. For example, a textarea field only has one 'value'. In your config screen there a several fields which should be populated with bits of the json data. I think you're one step away. Retrieve the json then assign the individual bits to your module config inputfields
-
@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.
- 23 replies
-
- 1
-
-
- alerts
- notifications
- (and 1 more)
-
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!
- 23 replies
-
- 15
-
-
- alerts
- notifications
- (and 1 more)
-
Creating a relational Databse with future Workflows
psy replied to Steve_Stifler's topic in Getting Started
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?
- 15 replies
-
- 2
-
-
- push
- notifications
- (and 1 more)
-
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
