Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by ryan

  1. @elabx title!=Test|test seems to work okay in testing here. Though note that there's no reason for the OR condition there, unless you've manually converted your database collation to be case sensitive, which I don't think I've heard of anyone doing before. Other parts of your selector to look at would be the created_users_id!=41, since that would exclude all pages created by the original superuser. Also city_id|cities=11669 seems like it might be worth removing temporarily to test as well, since it looks like it's two different fieldtypes (integer and page field?). In any case, if using 3.0.215 you probably want to update to 3.0.228.
  2. Last week we had a big update of Pro modules and this week we have another batch of Pro module updates. These are now posted and available for download in the relevant boards: ProDevTools Profiler Pro (v3) ProDevTools Sitemap XML (v4) ProDevTools ProcessWire API Explorer (v5) ProDevTools User Activity (v7) LoginRegisterPro Frontend File Inputfield (v3) FormBuilder Stripe Processor (v3) FormBuilder Stripe Inputfield (v9) If you use the ProcessWireUpgrade module, it can also tell you when Pro module updates are available. In addition to the Pro module updates, we also have a new dev branch core version available: 3.0.228. ProcessWire 3.0.228 primarily focuses on fixing newly reported issues. We'll likely merge this version to the master/main branch sometime early next week because it contains a couple of fixes that belong on the master/main branch. For instance, there was a bug with ProcessWire's pages_parents table (present for the last year) that could affect the result on has_parent selectors in some situations. There was also a bug found by @Robin S where ProcessWire's image fields weren't using the stored/cached value for width/height on images, and instead was pulling it from the image file, which takes more time. So for image-heavy pages, 3.0.228 theoretically could offer a nice performance benefit (especially in the page editor), and is a worthwhile upgrade. Thanks for reading and have a great weekend!
  3. This week I've been finishing updates for many of the Pro modules with new versions posted today for the following modules: FormBuilder (v55) ProCache (4.0.5) ProMailer (v13) ProDrafts (v10) ProDevTools Form Auto Saver and Reminder, also posted in FormBuilder (v3) ProDevTools Page Auto Saver and Live Preview (v8) ProFields Combo (v12) ProFields RepeaterMatrix (v11) ProFields Table (v25) ProFields Verified URL (v6) ProFields Textareas (v10) ProFields Multiplier (v15) These new versions don't necessarily contain new features, with a few exceptions. But they do contain maintenance updates for PHP 8.2+ and jQuery 3.6+ where needed. They also contain various small fixes, improvements or documentation adjustments. Pro modules not mentioned above will also receive updates in the coming week (or weeks). I thoroughly tested all of these modules with ProcessWire 3.0.227 before posting. But all of these versions are posted as "dev" or "development" versions. What does that mean? It means that that at the time it was uploaded, I was the only one using it so far, and thus they've only been tested thoroughly by me, today at least. The term "dev" doesn't mean that the version isn't stable. In fact, often times the dev version may be more stable than the last posted non-dev version. (Kind of like how the core dev branch is often more stable than the master branch). The dev designation just means that I can't claim it to be the most stable version until it's been out for a little while longer, with more people testing it. If you see a dev version posted that has been out for several weeks, then you can usually consider that the current stable version. The exception would be if it also says "beta", or something else to indicate it's a testing version. Early this week the core master/main branch was also updated to version 3.0.227. This version contains fixes for bugs reported since 3.0.226 master/main was released. A 3.0.228 bump is also in the works for the core master/main branch. I'll likely be working on Pro module updates for another 1-2 weeks here, along with issue fixes to the core. As a result, the 3.0.228 version will likely be merged to the master/main branch in the next couple weeks as well. I figure we might as well keep updating the main/master branch with small fixes and such until we get into more major dev branch updates. Thanks for reading and have a great weekend!
  4. @joe_g In that case the $user must have been a NullPage. I'll set it up to throw an Exception with a more clear error message when you try to save a NullPage.
  5. This week there have been a few updates to the core on the dev branch, but nothing major. Next week I'll be bumping up the version to 3.0.227 and then likely merging back to the master/main branch again. While there aren't major updates relative to 3.0.226, that means there isn't a lot to test or break, so it makes sense to keep updating the main/master branch until we get into more significant updates on the dev branch. In addition to getting into more significant dev branch updates, I'm also planning to put out version updates on nearly all the Pro modules in the upcoming weeks. Thanks for reading and have a great weekend!
  6. You would think that Stripe could come up with at least one web design/development related category. After all, they have "Alcohol", "Marijuana-related products", "Weapons Or Munitions", and "Betting Or Fantasy Sports", but absolutely nothing for folks like us… no web design, development, or any kind of design or programming topics. The only one that mentions anything online/internet related would be "Online gambling", so maybe that's the closest one?
  7. If you want to add hooks in your ready() method, you could probably call the ready() method at the end of your install() method?
  8. @prestoav Is it possible you've turned off URL segments for your admin template? That error comes from /wire/core/ProcessController.php (here) when it can't match up the current URL segment to a method in the Process module. It would be worth looking at the Network tab in your browser to see what the full URL is when it's failing.
  9. Happy 1st of September! Now that we've got the new main/master version out and running smoothly, I've been catching up with some client work this week. I'll need to do some of that next week too. But we'll also be fine tuning the core and fixing anything that comes up in issue reports. We may have have another master version out with these kinds of minor updates before digging into more major updates, feature requests and PRs on the dev branch this month. If you've not yet upgraded to 3.0.226 yet, I'd encourage you to give it a try. So far all reports have been positive and I've not heard of anyone running into any upgrade issues yet. Thanks and have a great weekend!
  10. After 8 months in development we are excited to bring you ProcessWire 3.0.226 main/master. This version has a ton of great new features, improvements and optimizations, plus more than 100 issue fixes. This post takes an in-depth look at highlights from this great new version. While there's even more in this version than is covered fully here, we hope this gives you a good taste of what you'll find in 3.0.226! https://processwire.com/blog/posts/pw-3.0.226/
  11. The master/main branch is now updated to version 3.0.225. Early next week I'll be adding a git tag for the version number as well. I usually like to merge dev to the master/main branch first, let it marinate for a day or two, and then tag it. That's because once we tag it, it triggers other services to pick it up and broadcast it. So letting it marinate for the weekend just adds a layer of comfort, for whatever silly reason. That's pretty much how I've always done it. When I did the merge, it reported 511 files changed, 76421 insertions(+), 23539 deletions(-), so there's quite a lot in this version. There's enough, that I'm going to need another week to document it all into a new blog post, which should be ready by this time next week. Our contributors list also continues to grow nicely with this new version. Thanks to all those that have submitted PRs, reported issues, and submitted feature requests. Big thanks to @matjazp in particular who has been helping a lot in identifying, testing, organizing and even coding the solutions for numerous issue reports. More details on this new version next week. Until then, thanks for reading and have a great weekend!
  12. This week we've been resolving a few more remaining issues, mostly those that take more time or discussion. So there's not many commits to the dev branch this week, but that also means we're very close to having the main/master version ready. I'm hopeful we'll be there by this time next week. If you have a chance to test the current dev branch please do, and let us know if you run into any issues. Thanks and have a great weekend!
  13. This week on the core dev branch is ProcessWire 3.0.224! Relative to 3.0.223 it has 25 commits and 17 issue resolutions (see dev branch commit log). I think we are within 1-2 weeks of having the new main/master version, so I'll be looking closely for any new reports. Consider us now in a dev branch feature lockdown in preparation for the main/master version. At this stage, there likely won't be any new features added or issue resolutions that would require significant field testing (at least not until the merge to main/master). If you have a chance to test the current dev branch version, please do, and let us know if you run into any issues. Thanks and have a great weekend!
  14. In a recent GitHub issue report, I was asked about output formatting in ProcessWire, and where more information could be found about it. I know I've written about it numerous times, and went to locate the documentation page, only to find we didn't have one! Output formatting is such an important topic, so here is everything you need to know. I hope you'll find it simple enough, but also useful and thorough— https://processwire.com/blog/posts/output-formatting/
  15. Like last week, work continued on preparing our next main/master version by working through remaining issue reports, this week with a focus on older and previously missed reports. Thanks for bumping up any that we may have previously missed. Thanks also to @matjazp for helping to identify and prioritize them. In addition, the version number was updated to 3.0.223 this week, as there were enough changes to warrant differentiating it from 3.0.222. It wasn't all issue fixes this week, as several minor additions and improvements were completed as well (see the dev branch commit log). Next week will continue along the same path. Thanks and have a great weekend!
  16. @Robin S Good call! Not sure how I forgot about that one.
  17. This week the dev branch version remains at 3.0.222 but updates and issue resolutions continue as we work towards our next main/master version. I think we are quite close. Thanks for reporting issues in our processwire-issues repo. If there are older issues that I've missed, also feel free to reply to them and that'll bump it to the top when we sort by last-updated, ensuring it gets eyes on it. Thanks and have a great weekend!
  18. @da² Looks like a good form class. I experimented with removing that cache in InputfieldForm, but found that it was worthwhile to keep as it gets called 5 or 6 times in page editor testing, and removing it adds more overhead than I'd like. So instead I updated it so that $form->getErrors(null) forces it to re-check all the fields, clearing/bypassing that internal cache. So in your form example, you'd call $form->getErrors(null) rather than $form->getErrors(), and then it should do what you were expecting. https://github.com/processwire/processwire/commit/b77d7f98c64edda4d49b2415e092e804e4c37e70 There is no problem with it. It takes care of figuring out namespace issues and compiles a new version of the file that resolves them. Since you were using 'use' statements at the stop, I was figuring you didn't want it adding more namespace logic behind the scenes. But since you've got templateCompile=false; then you're all set.
  19. @dotnetic I don't think there's an option like that for findRaw, but you could still use findRaw, as it'd be fast and simple to get them in the order you want: $getIDs = [ 1014, 1, 2 ]; $getFields = [ 'id', 'name', 'title', 'url' ]; $rows = []; $a = $pages->findRaw($getIDs, $getFields); foreach($getIDs as $id) { if(isset($a[$id])) $rows[] = $a[$id]; }
  20. @hipperman When you include() ProcessWire's /index.php file, that'll leave you with a $wire variable, which is the ProcessWire instance of the site you included the index.php file from. From there, you can access any ProcessWire API variables from that $wire variable, i.e. include('/path/to/your/pw/index.php'); $page = $wire->pages->get('/about/company-history/'); echo $page->body; If need be, you can even boot multiple different instances of ProcessWire, but just make sure they are all running the same version.
  21. @dotnetic The getByIDs method should do it: $items = $pages->getByIDs([ 4, 2, 1 ]);
  22. @da² This way of processing a form with the process() method was introduced in PW 3.0.205, so 3.0.210 would have been the first main/master version to support it. The method wasn't present in 3.0.200, so I'm thinking most likely you were using the processInput() method instead? (example here). But it may not matter, as the process() method is just a front-end to the processInput() method to provide a more convenient API usage, as it returns a true or false as to whether the form was processed without errors. But that distinction is significant for your example. It assumes processing the form is a one-time thing and that you aren't going to manually add errors to the form once it has successfully processed, as identifying errors is part of processing. In your case, you are doing a secondary validation manually, adding errors after the form has processed. That's new to me, but if you find it useful then I'm all for supporting it. With regard to "forever cache", the cache is a request cache, not a forever cache. It is a runtime memory-only cache for the one current request, as presumably the same exact form instance won't be processed multiple times in the same request (or at least shouldn't be). The reason for the cache value is that it has to recursively iterate through every single Inputfield in the form to ask each whether it had any errors. For a large form, it can be enough overhead to warrant caching that information, as the method may get called multiple times in the request and have to repeat the same task. But is it worthwhile enough? Maybe not, given your use case. I'll look into dropping it. When you set an error, it will remain in the session until it is displayed. This is because redirects are often involved in forms, in order to prevent re-post by re-load. Form errors would be lost if they weren't remembered until used. This is because the process() method determines if there are errors and returns true (no errors) or false (errors). The processInput() method does not tell you that information and so you'd have to check for errors manually afterwards. So your first example is checking for errors BEFORE you have manually added an error to it (which is what the process method does, and sets that cache), while your second example checks for errors AFTER you have manually added an error. This is why the results are different. Unrelated, but I recommend putting "<?php namespace ProcessWire;" (or any namespace) at the top of your template file, OR setting $config->templateCompile = false; in your /site/config.php file, just so that PW doesn't attempt to unnecessarily compile your template files. Maybe you are already doing this, but just mentioning it just in case.
  23. @kalimati That file is not actually included in the module. When you install the module, it downloads the Google Client API library directly from Google. It looks like there's a bug in the version you have installed. Actually, I remember that one, they had the arguments in the wrong order for an implode() call. That's a simple one to fix if you want to edit the file yourself. Another option would be to upgrade the library. https://github.com/googleapis/google-api-php-client/releases/ You can check the box to change the version in the module settings, but unless you are also seeing other errors, I would probably just edit the Resource.php file directly and fix it, so that you don't have to go through re-authenticate. Here's the change to make on line 297 of /site/assets/GoogleClientAPI/google-api-php-client/src/Google/Service/Resource.php // $requestUrl .= '?' . implode($queryVars, '&'); // OLD $requestUrl .= '?' . implode('&', $queryVars); // NEW
  24. @bernhard I don't think there's much crossover between Drupal and PW on the software side, but I think there are other similarities. I did develop in Drupal for awhile (before ProcessWire) and while I liked it, I don't think ProcessWire inherited many ideas from Drupal on the technical side, other than some of its directory names. I thought Drupal already did a good job of doing things its own way, and I saw no reason to follow a similar path. I wasn't going to be able to make a better Drupal than Drupal. Not to mention, some of my own preferences also made me not enjoy working in it as much as some others do. Instead, I'd say it helped to cement some of strategies in ProcessWire to be the opposite of those in Drupal, because it seemed like there was more opportunity there, and more consistent with the way I wanted to work with the tool. For instance, at least at the time, Drupal's output/markup was really mixed around in lots of different files and components, and it seemed very opinionated about how it should all work. While that's great for being able to plug in components and use things in a more turn-key and consistent fashion, I found it challenging for the way I wanted to use it, as much designer as developer at the time, and especially on an e-commerce site I had to build and maintain. So that's why ProcessWire is very non-opinionated about how you handle your output and markup, and why it's always been largely markup agnostic. That's just one example of many things. But what I really liked about Drupal was the community behind it and how passionate people were about using it. To them it was not just a software, but a timeless tool with many facets and uses, one that you could build anything in, at any scale, and that had a real following, positive reputation and quality community. I thought it would be great if ProcessWire was similar in those respects.
  25. @LMD I think maybe this is what you want? This is saying to match template=repeater_gallery on the first argument to the method: $wire->addHook('Pages::saveReady(template=repeater_gallery)', function($event) { $page = $event->arguments(0); $event->message("Saving page with template=$page->template"); });
  • Create New...