![]() ![]() $items = wire("pages")->find("template=basic-page") $items = $pages->find("template=basic-page") $items = pages()->find("template=basic-page") Use a selector to retrieve multiple pages While each section of examples below provide identical results, the first two calls of each section (using the function calls) will likely be recognized by your IDE/editor, while the $variable versions likely won't. Here's a few examples, each showing identical API calls. This is because an API variable like $pages (and others) are mapped in such a way that pages()->find("selector") and pages("selector") are equivalent. In some cases, using the API functions will result in shorter API calls. Basically, it makes life easier and coding faster. So by using pages() rather than $pages, you can more easily derive the benefits of your IDE knowing everything about the possible method calls (auto-completion), return values and argument types. Whereas, IDEs immediately recognize the function call versions of the API variables. The solution is to use a little phpdoc like /** Pages $pages */ to tell the IDE what $pages is, but that's a hassle. Likewise, your method calls off of API variables won't have known return values or arguments that the IDE can help with. If you type $pages->find() it may highlight $pages as an undefined variable (even if it isn't actually). When working with template files in an IDE like PhpStorm (or others), it probably doesn't recognize what the API variables are. Now you can just access page() and it doesn't matter if $page is in scope or not. You would either have to pass that $page variable as an argument to the function, or you would have to access it from wire('page'). Lets say you had a custom function you created where you need to access the $page API variable. For instance, rather than $pages->find(), you could use pages()->find(). The functions API is simply all the core API variables being callable as functions. I also took the opportunity to use our new functions API updates, and new region() function, both of which are described further in this post. All additional markup is generated from include and view files in /site/templates/includes/, which are largely rendered by the $files->render() API function. It's using delayed output with the _init.php file establishing the output regions, and the _main.php file handling the main output. In terms of the site template files, they have largely been re-developed to simplify a few things. We've also added a few new features and details in this site, and will likely continue to do so. But I think that's okay now, as the site really is about being a demo for ProcessWire rather than any kind of serious directory of buildings. Though admittedly, the new site lacks the personality of the old one, as there aren't really any graphical elements or branding details saying anything about skyscrapers. The end result is completely stock Uikit, which made it quick to develop, but also likely more useful to those that would want to use the site profile as a starting point. ![]() The previous iteration wasn't even responsive, consistent with the time it was developed. This week I re-developed the front-end using Uikit so that now the site hopefully doesn't look like something too old school anymore. Our demo site hadn't really changed much in the 5 years since it launched, and while we've kept the ProcessWire version that's running it up-to-date, the front-end really hadn't changed at all. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |