Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


heldercervantes last won the day on March 28 2018

heldercervantes had the most liked content!

Community Reputation

455 Excellent

1 Follower

About heldercervantes

  • Rank
    Sr. Member

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Porto, Portugal

Recent Profile Visitors

3,547 profile views
  1. Does not passing $options produce a different result? It's weird, I've used this module a bunch of times and never had such an issue, but I usually don't specify options on resize and go with the default.
  2. Just to add a suggestion. This field can't be used as a condition for another field's visibility. It's an easy fix though, just have to add an ID to the field (matching the name) and it starts working.
  3. Found the issue. To whoever it may concern, as of this day the select file fieldtype doesn't support being a condition for other field's visibility. It's easy to hack though. On the module's file, find the render function and add the id property to the <select> element that it outputs, with $this->name as value. That will make it work
  4. I've used page field visibility according to a select options value before with good results. But can't seem to get it to work with a file select field. Here's what I'm doing: This all lives in a repeater. The file select (call it myFile) points to a folder and I can select files correctly. Then there's a (call it description) field that should be if a specific file is selected on myFile (say x.php). Editing the fields inside the repeater, `Show this field only if` is set to: myFile="x.php" I tried it with single or double quotes, with or without the `.php`, and the result is the same, the field is always hidden. In previous similar implementations, I've used select options with a validation such as `myFile=1`, now I'm hoping to improve this method, excluding the need to update the files field every time something is added, and also make it a bit less cryptic to manage the fields' visibility.
  5. I have also on occasion tweaked the styles for the markers, so that the active one is opaque and the others transparent. That helps when you have a bunch of them close together.
  6. Sorry this is going to be vague but... I've hacked it to support floats in some projects. It's not too hard. Just had to look in the module's code where the fields are defined and it's relatively easy to find the INT and change it to float. You may have to do the same in the DB as well. Takes some fiddling. I wish I could be more specific, but after formatting my machine I'd have to go through a bunch of backups to find actual code.
  7. heldercervantes


    Hey guys. Fresh off the oven. We're still polishing a bit, but went live anyway: https://inovtex.com/ Sorry this one is in Portuguese only, so you'll probably need the old google translate for it.
  8. Yep, that's exactly the behavior I was looking for. Time to get experimenting Thank you all
  9. Hey there. Anyone know of a clever approach to illustrate an options field with an image? I often do modular content editors using a repeater and an options field for the type of block. The repeater has all fields, and each fields' visibility is configured so it appears only when it's relevant to the chosen block type. This is cool, allows a lot of flexibility, but on more complex solutions I sometimes find that the admin could benefit from seeing an image that illustrates the option that's chosen. Kind of like the theme choosing step when you install PW. Any ideas on how to do something like this? Thanks
  10. Yup. Add /wp-admin to the URL and you're in the login screen. They made some design changes. Maybe whoever did it was more comfortable in WP?
  11. Disclaimer: Complete noob in security here. So, at the risk of sounding silly, would it make sense to keep the key in a different server? I mean, if the site's server is compromised, the key would be visible in the code. So, I'm thinking the key could be stored in a different server that's "completely airtight", and the only thing it does is listen to a key request from the main site's server, checks the IP and lends it the key. So any site scripts that needed to handle an encrypted field would have to make that request first. Does this make sense? Or would a breach where someone can access the DB + PHP files be so far gone that they'd also easily make the server request and expose the key?
  12. Well, encryption per-se is not mandatory, but "Data protection by design" is: https://gdpr-info.eu/art-25-gdpr/ They give leeway to choose an approach, but ask us to do something about it and not just let the info lying around for easy picking. Since pseudonymization is too complex for small to medium projects, I'd say our best bet would be on encrypting sensitive info like emails, names, id numbers, phones and addresses. As far as the things we build, there shouldn't be much hassle. Unless you're building apps that store medical records or something like that.
  13. Well I just finished writing up the privacy policy for my site. That was a hand full. Yeah, information backups will have to be considered carefully. Or just don't do backups like most people Now, about personal data anonymization and pseudonymization. What can we do in a PW installation to comply? Can something be made to automatically encrypt PW users data or pseudonymize it? This particular part of the requirements is what's driving me crazy.
  14. It doesn't necessarily have to be an expensive thing. Most small business' websites don't require personal information from their users. Right now I'm looking at a list of 20 sites I've built last year and only 3 or 4 store user's emails. No biggie there. Look at these guys' contact page and the privacy policy they have. It's a great reference for most cases. Now if you do store data, you'll have to be careful. I don't want to have something in the privacy policy like they have: "This data is currently stored in an identifiable fashion; a limitation of the content management system that this website is build on (WordPress). Pseudonymisation, meaning that the personal data can no longer be attributed to a specific user without the use of additional, separately stored information (key), is a requirement of the GDPR which many web application developers are currently working to fully implement. We are committed to implement it on our website as soon as we are able to."
  15. By the way, has anyone seen a website that already takes steps to comply with this? I'm seeing a page for a webinar on the subject with a registration form and no consent warning or even privacy policy link anywhere. I'm clicking google ads for companies selling consulting services that don't seem to have anything in place either.
  • Create New...