Loges

Thanks, I really don't know why I couldn't get that working. I tried that previously. Came back with your answer tried again and it's working. An attack of those 'walk away and come back later' moments. Thanks very much for the speedy reply.

Hi, I've spent ages trying to work this out, so I'm hoping someone knows the answer. I'm writing a class to handle form submission to textarea fields. Sometimes it will be an RTE (CKEditor) field and sometimes it'll be plaintext textarea and I'm wanting to purify/sanitize whilst keeping line breaks. I *think* I've got solutions for both but for the life of me I can't figure out how to get info on the target field via the API on whether it's a field that uses the RTE or not. I'm hoping I should be able to do a check against the field's inputfieldClass but I can't see how to access that property from the API. Any help appreciated (or if there's a sanitize/purify option that works for both that's even better). Best I can get so far is $wiresanitizerpurify$inputstr $cleaned = $wire->sanitizer->textarea($inputstr, ['multiLine' => false, 'newlineReplacement' => "<br/>", 'stripTags' => false]); //for RTE textarea fields

+1 Been using the devs as they come out each week and only found a couple of very minor issues that were fixed almost immediately. Also been using a few of the new features, it's pretty amazing what's been added in the past 12 months.

Yes that's what I do for the most sensitive data (disclaimer also a relative noob). For those sensitive fields there's nothing readable on the PW server and it calls a remote server to decrypt - basically exactly as you've outlined - checks the IP address of the incoming request then does the decryption and returns as required. It just means that any MySQL dump from either server in isolation is useless, and even if the MySQL dump and the PHP files from the main server are available it's one more step away. (The remote server MySQL only contains a PW ID key and the encrypted data so nothing identifiable really). So it's not perfect but would require someone gaining full access to the server in situ (ie on it's current IP address) rather than just hacking a backup somewhere. Given the data is identifiable but relatively innocuous I hope that's enough to get anyone malicious to give up and go after one of the millions of Wordpress sites Backups are (maybe wrongly) really my biggest concern. Goodness knows how many there are floating around with web hosts doing auto backups, sitting on my own hard drives, backups to Dropbox, sitting in PW database backup folders on the server etc Again, I'm not dealing with catastrophic data (eg credit cards) so I figure a level of hackery is OK. For one site we store a person's bank account number so we can generate batch bank payments to them (ie it's nothing that's not sent around on an invoice - we can pay into the account but not draw from it obviously) but I really didn't want hundreds of names, addresses and bank numbers sitting in a MySQL dump in clear text anywhere.

Yes I envisage the fields to encrypt would not be searchable. Eg I wouldn't encrypt City, Gender, Broad Age Range, but I WOULD encrypt street address, date of birth. So the broad demographic data is searchable (and not overly sensitive personal data), whereas the specific personal data is encrypted (and not searchable - and not needed to be). Would another option be to just basically hash the values (with a key to unhash them), so the search would look to match the hash string rather than decrypting everything? That would only work for exact string matches I suppose and would need some intervention in the find query eg $pages->find("template=person, city=".hashStr('London').") where the hashStr() function converts to the hashed value? That would still make the MySQL dump/tables unreadable to the average or low level person whilst retaining some level of searchability?

Thanks @BitPoet I'll have a crack at a basic version that really just makes it a bit harder to get into. I'm really just looking to make it hard enough that it's not worth the hassle trying to crack for an opportunist. I wouldn't be comfortable (or capable) of more than that, and given the low level personal data that's all it'll need anyway. it sounds like you live and breathe this stuff, whereas it's not an area I've spent much time in. Do you have a recommendation for settings ie I take on board not using AES256 with ECB - are there standard settings that you'd recommend? I'm assuming we're talking about the openssl encryption module (maybe showing my ignorance here)? Given my low level requirements what's my best bang for buck IV generator? Thanks

Hi all, I'm building my first PW site that will contain user personal info (it's a job matching site where people sign up to create a profile where some is public, some is used by admins in the back end). Now obviously people are signing up and it's all transparent what info they're providing and what we're doing with it. My concern is that this info is stored in fields in the database in clear text so if a MySQL database dump goes missing it's got a lot of personal information stored in it. Frankly there's nothing too private (we don't collect DOB, financial data etc) but it is definitely personal data. This is in Australia only so not as onerous as GDPR but the new privacy breach reporting/notification laws (and general good practice) mean I want to minimise any potential issue. On other sites I've built (non PW) that handle personal data I do a basic encrypt/decrypt for those fields so the database dump is gibberish (not perfect as obviously with the PHP files it can be decrypted but the SQL dump by itself is safer). I figure I could create a new fieldtype/inputfield in PW where i do a similar thing, but then that of course means any $pages->find() requests on those fields won't work. Has anyone dealt with a similar issue and (hopefully) come up with an elegant solution? Thanks

Many thanks

Hi all, An issue that I've only discovered on a site I've recently upgraded from 3.0.42 to 3.0.88. This does NOT affect SuperUsers but DOES affect users who I've set up as Admins with user-admin permission. If one of those users tries to create a new user it throws the following error. Has anyone else seen this, can replicate etc? I assume something has changed in the core as part of the User upgrades a few versions ago, but no idea why it would work for SuperUsers but not others. Error: Uncaught TypeError: Argument 2 passed to ProcessWire\ProcessUser::checkSaveRoles() must be an instance of ProcessWire\User, instance of ProcessWire\Page given, called in /sitepath_redacted/wire/modules/Process/ProcessUser/ProcessUser.module on line 356 and defined in /sitepath_redacted/wire/modules/Process/ProcessUser/ProcessUser.module:368

I've found a way around this - by adding an extra GET variable to the pw-modal link that I use to create the new page then checking against it. Still may not be the best way so if others have better solutions I'm happy to learn.

In a module I'm writing I want to run a hook function when a page is saved EXCEPT for when the module creates it's own page. So of course the problem is that as part of creating a new page it triggers the after save hook which I don't want in that case. I've tried with a session variable hoping that would give me a toggle (as seen below) but it's not going saving for some reason (I've tried with a blunt $_SESSION['newPageCreated'] non-PW session variable too). Snipped down code below. Not even sure if this approach is the best way to go so happy to hear alternative approaches if I'm trying to fit a square peg into a round hole this way. public function init() { // add a hook before the page is added (to auto generate a name) $this->pages->addHookBefore('added', $this, 'beforePageAdd'); // add a hook after the $pages->save $this->pages->addHookAfter('save', $this, 'afterPageSave'); } public function afterPageSave($event) { global $wire; $mypage = $event->arguments[0]; //handle what to do if this is a modal popup if(in_array($mypage->template, $this->tplToTransfer) and $wire->session->get("newPageCreated") === false) { wire("session")->redirect($wire->config->urls->root."post/admin/close-modal.php"); } $wire->session->set("newPageCreated",false); } public function beforePageAdd() { global $wire; $parid = $this->input->get->parent_id; $parpage = $wire->pages->get($parid); $newTemplate = "templatename"; $wire->session->set("newPageCreated",true); if (in_array($partpl, $this->tplToTransfer)) { $p = new Page(); $p->parent = $this->input->get->parent_id; $p->template = $newTemplate; $p->removeStatus(Page::statusUnpublished); $p->save(); $wire->session->redirect("../edit/?id=$p->id"); } }

That is exactly what I mean - thanks very much!

Hi all, Maybe I'm thinking about this the wrong way but I'd like to create a new field that is a Select where the user can select from the list of fields in the CMS. Just like you'd select from a list of Pages (but in this case fields). Wanting to do a "mapping" like is done in the Pro module Form Builder. I figured it would be like a normal Page Reference where the parent is the Admin>Setup>Fields page but that doesn't show anything. As a result I basically want the ID or name of the field chosen so I can reference it later (in the same way as Form Builder does I guess). Thanks

@Xonox have you used template caching at all? I really don't use template caching on any of my sites except one, which is the only one i have seen the same problem. May be unrelated, it happens even after I turned all the template caching off. Adding the namespace didn't seem to help for me. I also have a bunch of files in the templates folder that don't render as visible templates (basically reusable chunks) so I think that makes them less likely to get checked/recompiled (they just get included in actual rendered templates). Haven't gotten to the bottom of it and it's a site that rarely gets dev changes so I just delete the compiled versions whenever anything is changed in those template files and it's fine. Haven't tried re-installing and frankly for my affected site it's not worth the effort, but would be interested if anyone finds a solution or explanation.

Yes Horst is right, those IDs are collected in a session array, added to as articles are viewed, using implode to convert to string.