psy

@LostKobrakai OK, thanks for enlightening me. Was just thinking that if some scumbag got into the db, seeing stuff Base64 encoded would be one more step, rather than having the json string in an immediately readable human language. Main point of the post was warning of the flakiness of PHP serialize/unserialize

This week I was lured to the dark side (my client's own words) to work on a CMS that's not PW or WP. I didn't stay long and it reconfirmed by love of PW but that's beside the point. A problem I encountered was not directly related to the CMS but to PHP itself and how it handles Json serialize/unserialize. Everything functioned for a while then crashed monumentally without any discernible reason. A Google search turned up the following article: https://davidwalsh.name/php-serialize-unserialize-issues Seems to me not only does this solve the problem, base64 encoding data stored in the database would add an extra level of security/privacy. Just sharing...

This works for me... clinics (events) are listed under a Month Year heading. $clinics = $pages->find('template=event, start_date>=today, limit=6, sort=start_date'); if (!$clinics->count) return; $datetime = wire('datetime'); foreach ($clinics as $clinic) : $currentDate = $datetime->date('F Y', $clinic->start_date); if ($clinic->id == $clinics->first->id) : // first clinic?> <h3 ><?=$currentDate?></h3> <?php else : $prevDate = $datetime->date('F Y', $clinic->prev->start_date); if ( $prevDate !== $currentDate) : // different month and year ?> <h3 ><?=$currentDate?></h3> <?php endif; endif; ?> <div class="event-summary clearfix"> <?php // event details here ?> </div> <?php endforeach; ?>

The API vars, $pages, $log, $sanitizer, $fields, etc aren't automatically instantiated inside custom functions. You may want to start your function eg like: $log = wire('log'); $pages = wire('pages'); ... then you can use them as normal

Yes, maybe the $pages object isn't set yet ? but no $ sign before pages... wire('pages')

try wire('pages')

My thoughts FWIW... the dependent modules, eg Fieldtype & Inputfield version numbers should be in line with the module version number. To keep things consistent, if the dependent Fieldtype or Inputfield are updated, the module version should be updated too to alert devs of the change

Thanks for all your suggestions. I've actually narrowed down the cause however don't know how to fix... It's related to https. Both site htaccess files were set to https only. Site A templates were also set to https only. Site B templates defaulted to http or https. Site B was an older site upgraded from 3.0.25 to 3.0.110. I can now get the imported fields/templates/pages in Site B working by setting the templates to http or https. This however raises another issue, ie all assets - images, forms, etc - are served as http and throw errors, and in the case of forms, don't show on the front end at all. Will do more digging around the forums and if you know how to resolve, please do share

@horst Site A is 3.0.107 and Site B is 3.0.110, and yes, I encountered the parent/child issue which is why I did it step by step. @adrian yes, the templates do have multiple field types, including some new ones including fieldset page. Maybe that's where the problem lay? Will take a look at ProcessMigrator next time. Thanks for the tip

I'm combining two PW sites into one, Site A into Site B. At each step, I did it bit by bit as the 'all at once' approach failed. First, I exported all the fields from Site A and imported into Site B. Any field types not supported by import/export, eg FieldtypeOptions I manually recreated. All good. Next I exported all the templates from Site A and imported them into Site B and copied across their associated template files. All good. Finally I exported the pages I needed from Site A into Site B - again, bit by bit to ensure it all went smoothly. From the admin side, it all looked and worked perfectly. Front end was a totally different story. All existing pages in Site B worked as expected. NONE of the pages imported from Site A displayed. They all ended in a redirect loop with no errors in the PW logs or Tracy Debugger. After some trial-and-error, I finally got it working with: - create a new template in Site B admin with no associated template file and just a title field - import the fields from the imported Site A template into the newly created template (both on Site B) - copy the Site A php template file into a new file that matched the new PW Site B template name and save in Site B site/templates I can deal with the above workaround. Just curious to know if I did something wrong or if the template import/export feature is problematic? ### Solution: While the export/import was a slow process, turned out the front end redirecting issue was unrelated. For reasons unknown, all templates marked as HTTPS only were the ones redirecting, ie all templates from Site A. Finally solved it by changing the $config->https to true in site/config.php Now the pages display correctly as https whether the template forces the issue or not.

Yep, not much activity in this forum so as a new Padloper user, thought I'd share my feedback on this module here, originally posted in the Padloper forum:

@Tom re ecommerce stuff...I've used WooCommerce and come out blue, battered & beaten at the other end. I've also integrated the BigCommerce API with PW. Am now working on site with the PW premium module Padloper. IMHO: WooCommerce is horrible on every level BigCommerce and any other SAAS platform, eg Shopify, are easy enough to integrate into PW and while they dont always have the perfect workflow solution, suit bigger shops Premium ecommerce PW module Padloper is raw, pure PW, takes a bit of getting used to and is great for smaller shops

@PCuser not sure if it's related but I've often had similar errors when copy/pasting sample code from the PW docs/forums. Maybe it picks up some 'invisible' extra code or spaces? Now I copy/paste to a plain text editor first before adding to my template - same as I'd do for MS Word - and it seems to fix the problem

@Robin S Going through the same dilemma. Yes, I could do the kindly thing and add client sites to my google developer maps account but : how many until it impacts my map view limit? what happens when a site takes off and my gmap views go through the roof? how do I bill a client 5c and would they pay it? how do I work out which client to bill for minuscule amounts? how do I convince clients to sign up for a Google Developer account? I absolutely do not want to know my clients' credit card details for my sake as well as theirs Already have a couple of sites that I need to think about this but it's doing my head in, and yes, there are alternate website map solutions but they don't have the same power in google searches which is a key driver for including Google maps for local businesses on websites?

@darrenc Yes 'pw-remove' works. Maybe it's about being consistent? Try using the <region> tag for all rather than mix-n-matching <region> & <div> Instead of using <div id="sidebar"></div> use <region id="regSidebar"> <div id="Sidebar">xxx</div> </region><!--regSidebar--> Then in your template where you don't want to display the sidebar, simply put <region id="regSidebar"></region> This has always worked for me and helps me keep track of the regions. Many roads up the mountain ?

@kongondo done & done ?

@kongondo I purchased Padloper last week and would like access to the subforum too please ?

Yes @pwired have heard all the arguments. The thing that annoys me most of all is Google. Google sprouts the importance of clean code, speed, well formed HTML, blah blah blah. My PW sites deliver and yet WP sites that fail with unrecoverable HTML errors, are barely responsive, have yawningly slow load times still rate in SERP pages. How does that work?

Rather than saving the entire page when you're updating the 'mark' field, try 'setAndSave'. This will save only the nominated field and not trigger another page save event. https://processwire.com/api/ref/page/set-and-save/

Quick update... my site already had a service worker registration file, PWABuilder. Each site can only have one service worker registration. With PushAlert's help, I managed to overcome this issue. Their software dictates that they register the service worker with a predefined file name, sw.js. Politely suggested they rethink this approach as other sites will have their own service worker registration files and who knows what problems may ensue if all vendors insist on their app registering the service worker? Awaiting outcome of that recommendation. Next, using the PushAlert cURL code, got notifications working on FF & Chrome. Haven't ventured into Safari territory yet as it involves a whole lot of baloney with Apple certificates. Sending notifications works well providing you don't mind getting double notifications when PWABuilder is installed with page cache/offline configured. Sigh... Plan is to continue development of PW integration with PushAlerts and, until service worker fluff is resolved, offer clients either push notification OR offline/fast page load. Will also do best to make calls to PushAlerts using WireHttp instead of their cURL code. Stay tuned!

Thanks for the replies and all food for thought. Just to get things going, I've used the PushAlert's CURL code for now in the module and it's working fine. Will experiment more with WireHTTP later. Cheers

Thanks @arjen I tried that with Postman and it didn't work. Suspect I had the right idea and wrong execution

This may be a question for @ryan but will ask here as it relates to module development. I've begun development on a module to integrate PushAlert (https://pushalert.co/) with ProcessWire. Had a few hiccoughs along the way due mainly to the fact that my website already had a service worker. PushAlert support has been fabulous and I can now send push notifications from my PW website via their console and still use my own service worker code for offline cache. There are two PushAlert APIs - JS API and a REST API. Both are needed for my module and it's a WIP. Plan is when a visitor 'Allows' notifications from my site, the PA javascript API will capture the subscription ID and store it in a PW field on the user template. That bit is still to be written. First step is to send a push notification via the PushAlert REST API to all subscribers. PushAlert doesn't have a PHP library in GitHub but its doco does have examples, eg to send a broadcast notification to all subscribers: <?php $title = "Notification Title"; $message = "Notification Message"; $icon = "https://yourwebsite.com/icon.png"; $url = "https://yourwebsite.com/"; $apiKey = "YOUR_API_KEY"; $curlUrl = "https://api.pushalert.co/rest/v1/send"; //POST variables $post_vars = array( "icon" => $icon, "title" => $title, "message" => $message, "url" => $url, ); $headers = Array(); $headers[] = "Authorization: api_key=".$apiKey; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $curlUrl); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($post_vars)); curl_setopt($ch, CURLOPT_HTTPHEADER, $headers); $result = curl_exec($ch); $output = json_decode($result, true); if($output["success"]) { echo $output["id"]; //Sent Notification ID } else { //Others like bad request } ?> To send to an individual subscriber or nominated subscribers uses the same code with a few extra items in the $options array. The module config will store the API Key and the base API URL. The functions will allow the developer to enter the appropriate slugs, eg 'send'. All good so far... I could use their recommended CURL stuff but would rather use WireHttp. Questions are: Is it possible to convert the above CURL stuff into a WireHttp post and if so, how, especially how to code the custom headers? I saw in the WireHttp class that the 'sendCURL' function was commented out with: /** * Send using CURL (coming soon) * * @param string $url * @param string $method * @param array $options * @return bool|string * protected function sendCURL($url, $method = 'POST', $options = array()) { 3. If not (1), then when is 'soon'? All help welcome. psy

Heads up for any PW developers who use parallax images on the front end of their sites. Chrome v67 has introduced a bug - grrrrr. A quick search found the solution for me: https://productforums.google.com/forum/#!topic/chrome/DC4IFvGXdIA;context-place=topicsearchin/chrome/category$3Awindows-10%7Csort:relevance%7Cspell:false In your CSS: /* google chrome 67 parallax bug fix */ .parallax { transform: translate3d(0,0,0); -webkit-transform: translate3d(0,0,0); }

@neophron If I read your original post correctly, you want to target each subpage individually for CSS styling, eg background colour, after it's rendered on the home page. If so, then I would add a class of the page name and/or template name and/or page id to the subpage template, eg: // Sub page template <div id="p<?=$page->id?>" class="<?=$page->name?> <?=$page->template?>"> // Your field output stuff here... </div> This ensures each home page section has unique style classes and ids to target. Then use your first method to render the subpages on the home page, ie: <?php foreach($page->children() as $p){ echo $p->render(); // will render the above } ?> Your CSS would then look something like: .subpage-1 {background-color: blue;} .subpage-2 {background-color: red;} .subpage-3 {background-color: green;}