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