Jump to content

ryan

Administrators
  • Content Count

    12,592
  • Joined

  • Last visited

  • Days Won

    689

Everything posted by ryan

  1. ProcessWire 3.0.133 adds a useful new $page->meta() method for a new type of page-specific persistent data storage, adds the ability for users to create their own bookmarks in Lister, and has a handy and time saving update for the asmSelect input type. Read on for all the details, examples and screenshots— https://processwire.com/blog/posts/pw-3.0.133/
  2. This week we’ll take a look at 3 different WEBP image strategies that you can use in ProcessWire 3.0.132+. Then we’ll dive into a major update for the Google Client API module, and finish up by outlining some useful new updates in FormBuilder— https://processwire.com/blog/posts/webp-images-and-more/
  3. This week I’m happy to report we now have WEBP support in ProcessWire thanks to a GitHub pull request from Horst Nogajski. This enables you to have highly optimized image output in PW and I think you’ll really like the difference it makes. Read on for all the details… https://processwire.com/blog/posts/webp-images-in-pw/
  4. In this post we take a quick look at the new version of ProFields Repeater Matrix, yet another new version of FormBuilder, and a new version of the GoogleClientAPI module— https://processwire.com/blog/posts/lots-of-module-updates/
  5. In this week’s post we’ll shift focus a bit and take a look at the latest version of FormBuilder (v38) just released today. It ends up being a fairly major release with a lot of new additions, optimizations and updates— https://processwire.com/blog/posts/formbuilder-v38-released/
  6. ProcessWire 3.0.131 adds support for partial/resumable downloads and http stream delivery, and contains several updates to our comments system, among other updates— https://processwire.com/blog/posts/pw-3.0.131/
  7. @horst Thanks Horst that's great news!
  8. Just a brief update today. I’m going to give it another week before bumping the core version, as I don’t think there’s enough changes yet to warrant a version bump. For whatever reason, several of my clients have needed integration with Stripe (payments) over the last few weeks. I’d not worked with it before the last month or so, but now all of the sudden am working with it a lot, because that's what my clients have asked for. I’ve found myself working on four different Stripe integrations on existing PW sites, both Stripe Elements and Stripe Checkout. None of these are for sites that have an actual “store” where they would need a cart, but rather just “pay for your reservation”, “buy this book”, “buy this song”, and “make a donation of $10”, “make a recurring donation”, type things. After doing a few of these, I thought it would make a lot of sense to have this built into FormBuilder, which would save us time on this stuff. So this week I built Stripe support into FormBuilder (using the Stripe Elements API). It’s already fully functional, so I will be releasing a new version of FormBuilder with this capability quite soon. To add a Stripe payment input to your form you just add a new field of type “Stripe payment for FormBuilder”, and then it asks you for some info about it (like amount to charge) and then your form works as a payment processor. Stripe has a clever way of making this all work, so that the user never leaves your site, but your site (and FormBuilder) never sees credit card numbers or anything like that, so it’s secure and you don’t have to consider things like PCI compliance. I've also got some other unrelated updates for FormBuilder that I'll be covering soon as well. Have a great weekend!
  9. Quietly and without interruption this week, our whole website (and all subdomains) moved from a single static server to a load-balanced multi-server environment, giving us even more horsepower and redundancy than before— https://processwire.com/blog/posts/processwire-hosting-upgrades/
  10. Work continued in closing out issue reports this week. We’re down to about 60 of them now, though if we subtract issues that aren’t reproducible, are already marked as resolved (close pending), may be moved to the request repo, or are a discussion (rather than something to fix), then we’re closer to half that number. Over these last few weeks we’ve been working on issue reports, but I’ve also been enhancing the core in small ways as well. This post will cover a few of the useful enhancements that have been made in recent weeks— https://processwire.com/blog/posts/pw-3.0.130/
  11. Like in recent weeks past, the primary focus this week in core development was working through the queue of older issue reports. Relative to 3.0.128, ProcessWire 3.0.129 contains 17 commits over 1 week, most of which are focused on resolving and closing out older issue reports. However, there have also been a few very useful additions too, and I’m going to cover them in a blog post next week. In terms of our issues repository, we are now down to 65 open issues and 777 closed (the closed number is a total over the life of this repo). If we subtract issues that are tagged as being fixed, not a bug or ready to close, we’re around 55 open issue reports (give or take a couple depending on when we check). Which is to say, there’s a lot of great progress here. And many of the remaining issues are minor things that might only affect one person, though still important nonetheless. Thanks to everyone that’s helping figure things out (such as Toutouwai, Matjazpotocnik, Netcarver and others), your help is greatly appreciated. Just now I also released a new version of ProMailer (v7) which accommodates many of the recent feature requests and fixes a few minor issues as well. There has been a lot of enthusiasm for ProMailer, pleasantly more than expected—thanks for your interest and support. Here’s the changelog for the latest version (v7) below. There is also more good stuff in the works for v8 as well. Changed subscribers list interface to use tabs. Added ability to remove all subscribers from a list. Added ability to remove filtered subscribers from a list (matching find query). Added ability to import subscribers from another list (creating a merged list). Added support for single, multi-select and checkbox custom fields. Added support for PW 3.0.129+ core WireMail blacklist (more details in next week’s blog post). Added several new options for custom fields (see new custom fields reference). Added documentation for conditional placeholders. Split the rather large ProcessProMailer.module into separate files/classes. Fix some display issues in AdminThemeDefault and AdminThemeReno. Various minor bug fixes and other minor tweaks, additions and improvements. Thanks for reading this quick update and hope that you have a great weekend.
  12. Relative to the last dev branch version (3.0.127) version 3.0.128 contains 40 commits, mostly specific to resolving older GitHub issue reports. If you are interested, here is the commit log: https://github.com/processwire/processwire/commits/dev — version 3.0.128 covers commits between March 2nd and today. We're down to about 77 remaining issue reports, mostly older stuff that didn't get covered in the past for one reason or another, but we're making good progress. Similar updates will be continuing next week, and I've also got several ProMailer updates coming out next week too. Hope you all have a great weekend!
  13. If all of this is correct, I personally think that the stakes are too high for sending any kind of email in a place where anyone can accuse another of emailing them and subject them to thousands in penalties from a single email sent by accident. It seems like that creates a dark market for people to pursue receipt of email as a litigation model. It seems like sending any email at all is huge risk where one accidental email could bankrupt you (reminds me of the US healthcare system). Personally, I wouldn't have the ability to pay a lawyer to even respond to such a complaint, so would be inclined to play it safe and simply remove email as a communications method from my business entirely. I don't think you could safely run a software like this one (IP.Board) with those kinds of restrictions. But as far as ProMailer goes, if people subject to those kinds of laws still want to use it, I do think I can support much of what's been mentioned so far. Actually I think it's a good opportunity for ProMailer as a product to provide answers for these kinds of needs, and would enjoy implementing solutions for them. But I consider everyone here my friends, and with the stakes being so high, I would prefer that friends dealing with such laws stay far away from any software or service involved in sending email. Sending email sounds like a death trap as dangerous as swimming with crocodiles. I understand some will take the risk anyway, so I'll do my best to make sure ProMailer has answers for these kinds of things. The only one I'm really not wild about is encrypting email addresses, just because that would place major limitations on the ability to search subscribers, which might increase the risks in other ways. For instance, Mike sends you a C&D letter, but you can't find Mike in your lists in order to remove him, so he ends up getting another email, and BAM, Mike gets to take over your life savings. But I think I can provide hooks for those that want to do it anyway. In my development version, this morning I added an option to log IP addresses with subscribe request and confirmation logs. It's off by default, but can be enabled in the module settings. As I understand it logging of IP addresses is not legal in some places, so anything that has potential to record IPs I usually keep disabled as a default. But the option will be there for those that want to enable it. With regard to a blacklist, we've been talking about it in the ProMailer board and I'm currently thinking a blacklist might be better supported in the core WireMail rather than just in ProMailer. That way you could blacklist an email address for anything in PW that might send an email via WireMail, rather than just ProMailer. For instance, modules like LoginRegister use WireMail to confirm account creation, so a lower-level blacklist could affect that module or any others too, in addition to ProMailer. That way an errant confirmation email or password-reset email won't cause someone to lose their retirement savings. I understand one of these blacklists can be individual email addresses, or entire domains, but am wondering about scale: are blacklists usually fairly small, or might it be an existing published list with thousands of domains/emails?
  14. Teppo, good points. Though on the servers I work from at least, you'd need access to the server account before you could ever get into the DB. Though I know this isn't representative of all environments. In general, I think DB backups are where there's more potential need to protect things. Those might be downloaded to the developers computer and then become more independent of the server, where encryption could actually be a more valuable protection. Encrypting emails does seem pretty silly given their purpose, so it's not something I'd do unless I had no choice, but for people where that's the case the good news is that it would be very simple to do.
  15. Thanks for your questions. I suspect that what they are really referring to with encryption has to do with using HTTPS, though I could be wrong. That's where encryption would matter most here. If they are instead referring to private storage of the data on a server/DB, then "user data" is probably too general a term. Things like SSNs or financial info would be confidential user data that you might want to encrypt with a user's password as the key, so that it would not be reversible except by the user. Things like an email address or website URLs probably not. That's because they are already public identifiers used by the internet as a network, passing through perhaps dozens of other servers on their way to their destination, and stored in non-encrypted logs by both originating and recipient recipient server. So if one is using some kind of confidential data as part of their email address, they probably shouldn't use it for... email. Storage of any data, whether confidential or not, is of course "protected" by the access control of the server. At the other end of the spectrum, if one can access data already, encryption doesn't add any protection if the means of reversing the encryption is located on the same server where the encryption occurs (as it would have to be to make use of it on a website). That's why I think that GDPR statement must be referring to HTTPS, since encrypting these things at the server side would require decrypting them at the server side, and thus wouldn't be very useful (false sense of security). Nevertheless, if it's something you want it do, it would be fairly simple to implement, and I'm happy to outline the hooks necessary to do it. The big drawback is that the data would no longer be searchable. But if one has the need for whatever reason, then yes, it's definitely possible A user can only receive a newsletter if they subscribed to it and also confirmed that they wanted to receive it by verifying their identity via email. So that could not be considered "unwanted" email since one has to specifically opt-in to receive it. However, if there are some kind of public blacklist services or lists that you want to use to prevent users from even attempting to opt-in to a newsletter, then I could definitely add support for them. I'm not aware of any at present, so if you are, please let me know and I can get a closer look. Though I'd think just the public existence of such a blacklist would probably invite unwanted email to those addresses, from outside the jurisdiction of the blacklist. ProMailer is not a tool for sending spam, and if that's someone's intention ProMailer is not the right tool for that. Regardless of tool, if someone can make false claims and subject someone else to $5k per email of penalties, then I would probably eliminate email as part of any business model in those jurisdictions. So if that's the case, email would be dead in my book and I'd move user communication to another medium like SMS or even traditional postal mail. You can only subscribe if you confirm it with your email address (double opt-in). So the only situation where you can subscribe is if you yourself confirm it from your email. You can test it out from here if you'd like. But if someone breaks into your email, then yes they could subscribe you. If that's a concern, then this is another situation where I would avoid email as a medium for communications. We do store the timestamp of both subscription request and confirmation. No IP addresses or information about the browser client are stored by default, but you can store the information on your own if you'd like to.
  16. This week ProcessWire ProMailer has been released, plus we’ve got a nice upgrade in our community support forum, and more— https://processwire.com/blog/posts/promailer-now-available/
  17. Glad you like the updates! Hope I didn't give the wrong impression, as I didn't intend to communicate anything about a "feature freeze" (as was stated in one of the messages above). At least nothing like that was, is, or ever will be planned, except maybe for a few days prior to a master version release. This is a stable project, but not a static one. There is no freezing or thawing, just the flow—I'll try to clarify... ProcessWire was originally built out of the needs of web development projects here, and that has always been a significant driver of what and when features are focused on at any point in time. When I add or improve something, it's usually because I'm going to be using it now and always going forward in actual projects, and by extension, can also support it in this project for everyone else. Of course, I only add/improve stuff that I know has significant benefit for all PW users, regardless of whether it's recognized in the short term or not. The other major part is features that arise from needs or contributions in the community here and on GitHub. My client projects are pretty similar to those of most PW users, which is good for the project. I'm always looking for ways to optimize and improve PW and its API, especially things that will save time in my and your projects, and this has always been the case. I'm driven by it. The feature focus is always holistic and never sacrifices backwards compatibility. And the product focus is on long term quality and sustainability, being the best tool for the job, not on being popular. The focus may largely be on issue reports right now, but this should not be interpreted to mean anything beyond resolving issue reports. I'm making continuous improvements and additions where appropriate along the way, as always. Perhaps they aren't big enough things to warrant blog posts now, but stay tuned — there is lots of good stuff on the way and currently in development. Every year there are a couple of important periods of good momentum in the issues repo, especially this time around, and so I'd like to continue that as long as possible and hopefully cover everything there. The difference this time is that we've got Netcarver expertly leading the effort as well as intelligently identifying which reports are still relevant. Plus there are a whole lot more "includes suggested fix" reports this time, thanks to people like Toutouwai and many others that know their way around the core extremely well, and often figure out how to resolve issues well before I do. It's a great community collaboration.
  18. Just a quick update this week rather than a blog post. I’ve been continuing to work through the PW issues repo with Netcarver and it seems to be working well, so am planning to just keep working through it till we’ve covered everything there. Thanks to Netcarver and everyone else helping there. When we get the issues repo to the point where it’s pretty empty, I thought we’d then move on to the requests repo and PRs if possible. While there have been several commits to the core this week (mostly related to the issues repo), I don’t think there’s anything major enough to warrant a version bump, so will get another week’s worth of updates in place before bumping it to the next version number. This week I’ve been putting the finishing touches on the ProMailer module, getting that ready for release. A copy of ProMailer will be available to current subscribers of the ProDevTools package that want it. A few people have indicated that they’d also like to see it as a product independent of the ProDevTools, and actually I think that makes sense because ProMailer has become a much more comprehensive product than originally planned, and it really needs its own dedicated support board, as well as dedicated dev and agency versions. So I will make those available separately from ProDevTools. If you are a current ProDevTools subscriber and you’d like to get the first version of ProMailer when it is ready, please send me a PM here in the forums indicating that, and I will get a copy to you when it is released in beta. Even if you aren’t a ProDevTools subscriber, but would still like to be notified when ProMailer is available, please send me a PM as well. If all goes well, it should be available by this time next week or earlier. Next month we’ll hopefully be back to work on the website here as well, and develop the new modules directory.
  19. @Autofahrn I don't really understand the code above well enough to know how to answer your question specifically, but one thing that jumps out to me is that you are interacting with POST data here, and that's something you want to avoid if possible. I looked in InputfieldPageListSelect and it doesn't have any getConfigInputfields() method of its own so I don't think it is adding anything here, instead, that method in InputfieldSelect is what you'd want to look at, particularly the part where it skips out early if the Inputfield isn't connected with a Fieldtype: if($this->hasFieldtype !== false) return $inputfields; . I would also try and use TracyDebugger with those bd() calls after your $cfg->set() to see what you are setting just to be sure.
  20. Version 3.0.127 contains almost 30 new commits, the majority of which are focused on resolving older issue reports. For more details on those commits, see the commit log. This latest version on the dev branch also adds a couple of new features that you might find useful. Specifically, two new Page status flags: “unique” and “flagged”. Below we’ll go into more detail about what these are and how to use them. https://processwire.com/pw-3.0.127/
  21. Repeater pages are just another type of Page so it should work fine to use the $page->if() when $page is a repeater item. Using an $page->if('repeater_field', ...) when $page is a Page that has the repeater field on it will also work since RepeaterPageArray is a type of PageArray. Though let me know if you were thinking of something different.
  22. This week we take a look at what’s in ProcessWire 3.0.126 which focuses largely on resolving issue reports, but also includes a handy new $page->if() method— https://processwire.com/blog/posts/pw-3.0.126/
  23. This week we take a closer look at the upcoming ProMailer module with a lot more details and screenshots. Plus an update on next steps with the new website and development schedule in the weeks ahead— https://processwire.com/blog/posts/promailer-preview/
  24. @Robin S Good point, I need to update that phpdoc in that file and will. I think it'll be more convenient for users if I keep it up to date with Sanitizer, rather than removing it completely. At least I like my code editor being able to recognize them as function calls rather than errors. As far as I know, there's not anything we can do phpdoc-wise to cover instruction methods (like text50_entities), since there's basically an infinite possible combination of them. Though will be translating the blog post into regular documentation for these new additions.
  25. Feel free to keep reporting here. I am checking in here for errors like this every few days and then fixing them as they come up. I'm guessing not too many more of these will turn up, as I've been continuing to update the logic in our 404 hook, plus logging 404s in ProfilerPro to catch any others that might have been missed.
×
×
  • Create New...