Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


ryan last won the day on April 3

ryan had the most liked content!

Community Reputation

17,296 Excellent

About ryan

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Atlanta, GA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. This week we’ve got a few new and interesting core updates in progress, though none quite ready to release just yet. So rather than releasing version 3.0.154 today, I thought we'd instead take a brief look at what’s coming over the next few weeks… https://processwire.com/blog/posts/processwire-updates-and-additions-in-progress/
  2. If one's goal is to get an up or down from an API call, then zero vs. non-zero is functionally and effectively the same thing as boolean. If there's an opportunity to make a method more useful by taking advantage of that fact, then I'll always do it. So yes, you'll find many examples of this in PW. That's always the strategy I've tried to embrace in the PW API and plan to continue going forward. To reiterate what I stated above, the primary purpose of the has() method is not to get an ID—it is instead to check if the system has a page matching the criteria or not, without actually loading the page. Whether the method returns 0 or false makes no difference in telling the caller that the system has no page matching the criteria. Likewise if the page does match the criteria (true vs 1+). Now if you are specifically looking for a getID() function, then yes of course the name "getID" is preferable. I'm happy to add getID() as an alias for times when one might be specifically looking for that particular need. But that's not what I was looking for here. And if anyone else's experience is similar to mine, we will more often be looking to see if the system has any page matching some criteria (whether we want the ID or not). Basically replacing instances where we might have used count() before, with a more efficient alternative. So I feel pretty strongly that the has method name and return value are optimal and consistent here.
  3. I hope everyone here is doing well, staying in, and staying healthy. Our town here is under a “stay at home” order, and it’s now the law that you can’t get within 6 feet of any other person when out walking. So haven’t left the house (other than for walks and bike rides) in about 2 weeks now. Though with the whole family home all the time, it admittedly feels a lot busier than before this Coronavirus stuff, I think because there’s now a lot more people to attend to during the day (especially kids). Not much silence compared to before. 🙂 Not a bad thing, just very different. If we’ve got to spend a few months, or even a year this way, it’ll be alright, so long as the internet keeps working. I’m just thankful to have a job where I’m already used to working this way, as I know many of you do too. It seems that this whole situation is going to move a lot of activity online that previously wasn’t, so I anticipate it’s going to be potentially a very busy and important year for web development. Online communication and content delivery is going to be that much more important for the world, making reliability, scalability and security every bit as important. These are always our focus, but just want to emphasize this even more as we look forward. With a world in temporary disarray, you can count on ProcessWire to be an especially stable and reliable tool that gets even better every week, and our community always a friendly and helpful place. I’ve got several things in progress in the core, but nothing far enough along to write about just yet. I’ve also been putting a lot of work into ProCache this week, which is long due for a version update. The module still has quite a bit of PW 2.x architecture that I don’t think is needed anymore, so I’m refactoring and improving quite a bit, in addition to feature updates. Thanks for reading and I hope that you have a good and safe weekend!
  4. @Robin S The purpose I was focused on for the method is to see if the system has any page that matches the given criteria. An example of the use case appears in the Template class updates here. It verbally makes sense in code for what it's intended for. Usually I'd use a get or count for that, I didn't need any of the extras that $pages->get() or $pages->count() provide, so thought we could eliminate some overhead. Plus I can think several other other cases where the same was true, so the need has resurfaced enough times that it seemed like good method for PW to have. The method returns the ID just because it already has that info either way, and it seemed potentially more useful (and 0|1+ communicate the same thing as false|true). I had also seen where you'd mentioned a getID recently, and since this method already has the page ID, I thought this also seemed like a good opportunity to accommodate that need too. So far I haven't come across a good use case for getID() in my own projects, outside of checking for existence of something (which 'has' seems like a better term for). But it certainly makes sense alongside the existing findIDs() method, though that method is more about accommodating a scale that find() can't. But it sounds like you've had use cases for it which means others likely have too, and that's plenty good reason for me. I'll go ahead and add getID() it as an alias of has(). Depending on what need you are looking to solve, I imagine this will help people to find what they are looking for more easily.
  5. This latest version of the core on the dev branch focuses on comments field updates, significant refactoring/improvements to ProcessWire’s core Template class and PagesLoader class (which is used by the $pages API variable), and we introduce a useful new $pages API method— https://processwire.com/blog/posts/pw-3.0.153/
  6. @adrian There are two options when you initialize your CommentForm that let you define what you want to be populated, and whether or not you want it to be editable. These are the 'presets' (array) and 'presetsEditable' (bool) options. I'm initializing with the new CommentFormCustom class below, but the presets options also work with older versions of PW: $options = [ 'className' => 'CommentFormCustom' ]; if($user->isLoggedin()) { $options['presetsEditable'] = false; $options['presets'] = [ 'cite' => "$user->first_name $user->last_name", 'email' => $user->email, ]; } $form = $page->comments->getCommentForm($options); As for using a local image for avatar, or deciding whether or not to show cite and email, this is where the CommentFormCustom class comes in handy. It leaves you in full control of the markup, so you can render whatever avatar image in there you want (whether CommentFormCustom or CommentListCustom), and exclude fields in your markup when conditions dictate. In previous versions, if you didn't want to show specific fields in the form then you would hide them with CSS. @AndZyk Here's how you might do that with a hook. This looks for markdown style links, i.e. [text](url) and converts them to HTML links. The regex may need improvement still, but maybe it's a starting point. $wire->addHookBefore('CommentList::renderItem', function($event) { $comment = $event->arguments(0); /** @var Comment $comment */ $text = $comment->getFormatted('text'); $textOriginal = $text; // look for markdown style links: [text](url) if(strpos($text, '](') { $regex = '!\[(.+?)\]\((https?://[^)\s\r\n;"\']+)\)!i'; $link = '<a href="$2" rel="noopener noreferrer nofollow" target="_blank">$1</a>'; $text = preg_replace($regex, $link, $text); } // populate changed comment text if($text !== $textOriginal) { $comment->set('textFormatted', $text); } });
  7. For logged in users, name and email are already filled in automatically and have been for awhile. There is also an option where you can make them non-editable, so that a logged in user can't modify them for each comment they make. But if you want to pull them from something other than "name" and "email" (which I think might be what you were looking for), then the new classes would definitely make it a lot easier to customize, and populate whatever you'd like in there. Likewise to render a custom avatar or hide fields, etc. The custom classes should open up a lot of new possibilities.
  8. I hope you are having a good week and staying healthy with all that’s going on with this Coronavirus pandemic. Here in Atlanta, they have closed the schools indefinitely, so I’ve got my kids with me during the work days for awhile, which started this week. That might slow me down with work and development here, but hopefully not too much. It might also take me a little longer than usual to respond to messages temporarily, as I get used to the new schedule. It’s a nice change of pace to have the kids home during the day, even if it slows work a bit. Thankfully everyone here is healthy and we don’t yet know of anyone being sick. But then again, nobody is apparently able to get tested for it, so who knows. It sounds like the whole world is dealing with this, I hope you and your families stay healthy and safe. I’m still working on the same client project I’ve been working on here for months, and of course doing it all in ProcessWire. This week the client project needed to do a lot with user-submitted comments, and I had to make a lot of major upgrades to ProcessWire’s comments system in order to accommodate them. Most of these upgrades are related to API improvements and making the comments field able to better handle completely custom markup for both comments and the forms to submit them. (Commit details). A couple new classes were added, and existing classes went through major refactoring. While there have been some nice API additions as well, there aren’t any breaking changes to the existing API, so it should all keep working as it always has. I’m not going to bump the core version this week because, as major as the additions were, I don’t think they will matter much to most existing installations, so there's little reason to upgrade for most. So I’ll continue plugging away here and save the version update for when there are some more things to share as well, hopefully next week. Thanks for reading and have a great weekend.
  9. @Zeka Thanks, I think I tracked down the issue (caching issue that occurs only when multiple date fields) and have pushed a fix on the dev branch. @szabesz From your /site/init.php you can set the location with $config->setLocation('classes', 'path/to/classes/'); for example $config->setLocation('classes', 'site/templates/classes/'); You can also use the method mentioned earlier by adding your own directories to the $classLoader. However, the more potential locations there are for something, the more overhead, so I would recommend sticking to the $config->setLocation() and keep all of your classes in one directory. This keeps everything fast and efficient. If that's the case, then you would have to add locations with the $classLoader and accept the overhead of doing so (though it's probably negligible so long as things don't grow too much). But I also think with that kind of structure, things look isolated when it comes to reusability, limiting their usefulness. That may be fine for your use case, but as far as classes go, one of the primary purposes is reuse and extending one another where appropriate, so you ideally want to keep them together. @bernhard ProcessWire preloads a few pages on every request, since they always get used. Preloaded pages are loaded as a group rather than individually, enabling it to boot faster. This happens before the init state for modules, so a module will not have the opportunity to specify a class for these preloaded pages, but a file in /site/classes/ will. See the $config->preloadPageIDs setting for a list of what those pages are. But essentially they are the homepage, admin root page, guest user+role, and superuser role. For your case, it sounds like only the homepage is a consideration here. I would suggest just asking PW to uncache the homepage at your module's init() state. This should force it to reload (when it's next requested) using your custom class. $homePage = $this->pages->cacher()->getCache(1); if($homePage) $this->pages->uncache($homePage); You can also use $config->setLocation() for this, i.e. $config->setLocation('fieldTemplates', 'site/templates/my-custom-directory/'); I think this is fine if you are just doing it once or twice, but if you find you are repeating yourself, typing out "/articles/fields" or similar in multiple places, then you always want to abstract away stuff like that into a single location so that if you ever need to change it, you change it in just one place. PHP functions are ideal for this. This will be simple to do, but when it comes to the directory and file names that you are using, I recommend using the exact same names that you do with your templates and fields, which will make it a simple matter to abstract away repetitive code or locations into functions. "All these directories" are 3 directories, 2 of which are for optional features that are disabled by default — the absolute minimum number of directories necessary to support these things. ProcessWire is focused in what is the most simple, efficient, familiar (as it relates to the admin), and maximizes reusability. It's not opinionated about it outside of those factors. For something like field-templates, a primary purpose of having them is so that you can reuse them across different templates (to avoid repeating yourself); otherwise they aren't that useful. For the structure that you appear to be using, it looks to me like your intention is to isolate them by template, so why have them at all? If the purpose is code/markup isolation (which is still worthwhile) then I think just using an include() or $files->render(); would be preferable, more efficient and flexible for your use case. So that's what I'd recommend there. The same goes for the new page classes—if you are isolating these things in the way you've suggested, it'll be confusing for classes to extend one another or be shared across multiple templates, and it'll take more overhead for PW to find them. If you don't intend to use them like that, maybe they can still be useful, but not nearly as much so. So at that point I would reconsider whether you want/need custom Page classes. Basically, you are using a highly opinionated structure for your site files, and that can be a good thing because you've decided where everything goes and have a plan/system for how it will grow in terms of your file structure. ProcessWire is built to support a lot of different types of websites and applications, and at any scale. But it's not opinionated about this stuff beyond the bare minimum, precisely so that you can be as opinionated as much as you want with your own projects. That's why you are able to build a more complex structure for your files that suits your need, and also why it's also just as suited for others that might prefer a simpler structure in their projects. There's also no need to feel obligated to use things like field templates or custom page classes just because they are there. The point of these features is to reduce redundancy and prevent you from having to repeat yourself. But you may have your own preferred ways of doing that—whether it's with functions, file/directory structure, or anything else, it's all perfectly fine in PW. A template file receiving a $page is the only assumption needed in ProcessWire and everything else is optional. So use these things when they help you do that, and avoid using them when they don't. The reason these features are disabled by default is because not everyone needs them. Personally, the only time I use field templates is for multi-value fields with lots of properties, like repeaters, where I need to reuse the same output/markup across multiple template files. Though custom Page classes I'm already using quite a bit and likely will in most cases.
  10. This week we have some major improvements to our core date/time Inputfield, as well as a new ability to specify your own custom classes for Page objects. Read on for all the details and examples— https://processwire.com/blog/posts/pw-3.0.152/
  11. @bernhard While that need hasn't often come up here, it sounds like it might be a common need elsewhere (?) per what you said, so I think it sounds worthwhile. Though I'm thinking maybe off the $files API variable as more obvious $files->diskPathToUrl() and $files->urlToDiskPath() type functions, but it would also be simple enough to have the $config methods respond to them too, so long as there's a at least one slash present in the value. Back to date/time API methods, were there any in particular that you thought were commonly needed but missing from PHP's built in set of tools? The two I found over time were the ability to produce relative date/time strings like "1 hour ago", and a common function that could accept different types of format strings (like those from date and strftime) so that's why PW's $datetime has those.
  12. The focus of the InputfieldDatetime updates that this topic is about is purely about the Inputfield element and wouldn't affect anything about front-end API of date fields. Basically just the means by which users input dates into the system. When it comes to working with dates and times at the API side on the front-end, that's a different topic, but I guess I've always seen this as something that PHP does really well already, particularly the DateTime class can be very helpful. PW's always trying to work alongside PHP and with what PHP provides, as much as possible. Maybe some people encounter areas of working with dates and times that PHP doesn't cover well, but admittedly I haven't yet in projects here. Though there are a few specific cases that are covered in WireDateTime ($datetime API var) mostly for date/time functions that were needed by the core, but can also occasionally be useful on the front-end. But I see PHP's date/time classes and functions as being the tools a PW powered site would typically use when working with dates/times. Not only is there tons of documentation and examples out there, but these are tools that many PHP developers are already going to know before they know PW. I like it when people can take stuff they already know when keep using it in PW. I'm definitely open to expanding what PW's $datetime provides if there's a really common need that PHP doesn't cover well. Though I'm glad to see there are also quality modules like the ones mentioned above, as that seems like a great way to accommodate these needs too.
  13. I’ve been working on some major upgrades to our InputfieldDatetime core module and they are just about ready, but because there’s a lot of new code involved, I just want to test things out more thoroughly before pushing to the dev branch. I’ll have more details on this for you next week, but here’s a summary of what’s new in our Date/Time Inputfield coming in 3.0.152: If you’ve used date inputs in ProcessWire before (whether in the admin, FormBuilder or elsewhere), you know that they consist of a text field with a configurable date format and optional jQuery UI powered date picker. On recent projects, I’ve wanted more options here. First off, I’ve wanted support for the HTML5 “date” and “time” input types, because on some browsers (mobile-based in particular) the browser implementation is quite good. On mobile clients (testing in Android Chrome at least), I find it’s actually pretty amazing, certainly preferable to the jQuery UI date picker. On desktop clients, I think the jQuery UI date picker might still be preferable, but the browser implementation is still quite good (though varies widely from browser to browser). So I’ve upgraded InputfieldDatetime to support both HTML5 “date” and “time” inputs as configurable options, as well as the ability to use them both together. Another thing I’ve often wished for when it comes to date inputs is the ability to have the Month, Day and Year isolated into separate selects. This is something that would work in any environment, and not require any particular feature support from the browser, nor would it require jQuery UI (like if you are wanting lightweight date fields in FormBuilder). This type of date selection seems to be the simplest, easiest and most portable way to go, and it’s something I’ve wanted for quite a long time. So support for this has also been added to InputfieldDatetime this week as well! Of course the order of month, day and year is completely configurable. Some other useful additions include support for HTML5 step values (date or time), minimum and maximum dates (and times), support for seconds in time selections, automatic localized month names in selects (via strftime), and the ability to ask for just month and year (when day is not applicable), or month and day (when year is not applicable). These updates—along with others—will appear in ProcessWire 3.0.152 on the dev branch within the next week.
  14. This week we’ve got a couple of really useful API-side improvements to the core in 3.0.151, among other updates. First we’ll take a look at a new $config setting that lets you predefine image resize settings, enabling you to isolate them from code that outputs them, not unlike how you isolate CSS from HTML. Following that, we’ll introduce and show you how to use a handy addition to our static language translation functions. If you’ve ever come across the term “abandoned translation”, you’ll really like what this adds— https://processwire.com/blog/posts/pw-3.0.151/
  15. @adrian @porl Since this post is in the ProFields board and you guys are discussing a Matrix Fieldtype (that's not related to ProFields), I'm a little worried people might get confused and think this had something to do with FieldtypeRepeaterMatrix (which I at first thought) but it appears you are discussing something different. And actually looks like maybe it would be useful for users outside of this board. Do you mind if I move the topic to one of the public boards, since it's not specific to ProFields, and may be useful others that might be using that Fieldtype?
  • Create New...