Jump to content

ryan

Administrators
  • Posts

    15,261
  • Joined

  • Last visited

  • Days Won

    1,144

Everything posted by ryan

  1. I always start from scratch when it comes to creating the fields and templates, and basic site structure, but rarely when it comes to the pages/content. On previous conversions I've gone into WP’s database and exports to migrate content. This new case is a little bit unique in that WordPress couldn't do everything they needed, at least not in a manner that was affordable or reasonable to implement, from what I understand. While some of the content is in WP, other content is coming from authenticated web services. Lots of the pages have some content, custom fields and repeatable blocks in WP, but there are also custom fields with IDs for external services that it pulls other content from at runtime. They are paying a couple other companies quite a bit of money every month to host their content through these web services and make it searchable. They pull from those services at runtime and output it all from the WP templates. It strikes me as really inefficient, but it all works fine and you'd never know it from the front-end. But it's also expensive for them and fragile to have these kinds of external dependencies, not to mention a pain to have to manage content (even for the same page) across different services. This is all stuff that ProcessWire does well on its own, so none of those external services are needed on the new site. Since the front-end of the site is already compiling them all into single-page output, I built a scraper to pull it directly from the existing site and put it into the right places in ProcessWire. Scraping might seem like a last resort, but in this case it was the fastest, most direct way to pull everything out since the content is split among different databases and services. Basically using WP as an adaptor for the services it is pulling from. Luckily I can edit the WP templates to modify the markup (adding wrapping tags or custom html id attributes, etc.) where needed make the scraper relatively simple. @MarkE
  2. We had a smooth rollout of the new main/master version 3.0.200 last week (read all about it here). If you haven't upgraded yet, consider doing so, this new version is a great upgrade. I'm going to add the 3.0.200 tag shortly after I finish this post, which should trigger other services (like packagist) to upgrade. I've had a new client project in the pipeline that I've been waiting to start till the new main/master version was out, so this week I started that project. Pete and I are working together on it, like we've worked on others before. It involves taking a popular WordPress site and rebuilding it completely in ProcessWire. I've done this a couple times before, but this time it's bigger and broader in scope. I always find the large site conversions to be great learning experiences, as well as great opportunities to show how ProcessWire can achieve many things relative to WordPress, in this case. At this stage, I'm having to spend a lot of time in WordPress just to get familiar with the content, fields, etc., as well as in the theme files (php and twig). The more time I spend in these, the more excited I get about moving it into ProcessWire. For this particular site, moving from WordPress into ProcessWire is going to result in a big boost in efficiency, maintainability, and performance. Part of that is just the nature of PW relative to the nature of WP. But part of it is also that the WP version of the site is kind of a disorganized patchwork of plugins, code files, and 3rd party services, all kind of duct taped together in an undeniably confused, undisciplined and fragile manner. (Though you'd never know it by looking at the front-end of the site, which is quite nice). This has been a common theme among WordPress sites I've dug into. Though to be fair I don't think that's necessarily the fault of WordPress itself. I always enjoy taking a hodgepodge and turning it into an efficient, performant and secure ProcessWire site. I love seeing the difference it makes to clients and their future by taking something perceived as a "necessary liability to run the business", and then turning it into the most trusted asset. I think the same is true for a lot of us here. We love to develop sites because it's an opportunity to make a big difference to our clients… and it's fun. Ironically, if past history is any indicator, I seem to get the most done on the core (and modules) when I'm actively developing a site. Needs just pop up a lot more. I don't know if that'll be the case this time or not, but I do expect to have weeks with lots of core updates and some weeks with no core updates, just depending on where we are in the project. This particular project has to launch phase 1 by sometime in July, which is kind of a tight schedule, and that may slow core updates temporarily, but who knows. I'll share more on this project and what we learn in this WP-to-PW conversion in the coming weeks. Thanks for reading and have a great weekend!
  3. @creativeguy Usually this behavior indicates that the site is missing an .htaccess file. Check your /Applications/MAMP/htdocs/giftfunds/ directory to make sure there's an .htaccess file in there. I'm guessing there isn't. If you don't have a copy of it, you can get it from here and then rename it to ".htaccess" (with the period in front).
  4. @bernhard Just tried to setup that situation and duplicate it but not seeing it. My best guess is that something is later overriding your $config->noHTTPS. But I would suggest not using $config->httpHost at all and instead changing it to: $config->httpHosts = [ 'localhost:8080', 'localhost' ]; …just in case the the port isn't getting communicated in the host name. You can also set your $config->noHTTPS to be conditional for the host names: $config->noHTTPS = [ 'localhost:8080', 'localhost' ]; Another thing to look at is to use your browser view-source to view those page editor view links to see if they really are https links in the source, or if something is changing them after the fact (or browser interpreting them as https due to a current or cached former .htaccess rule). Try manually setting $config->https = false; in your /site/config.php to see if that makes a difference. Do a bd($_SERVER['HTTP_HOST']) to see how the http host is communicated to PHP, just in case it's different from what you expect.
  5. @olafgleba Edit your /site/config.php file and look for: $config->httpHost and/or $config->httpHosts. In most cases the $config->httpHost should not be present (since PW will set it automatically at runtime), but the $config->httpHosts (plural) should be present, and it should be an array of http hosts ProcessWire is allowed to auto-detect and use. It will pick one of the hosts in that array to use for the request, so long as it matches the $_SERVER[HTTP_HOST]. If it can't find one that matches the $_SERVER[HTTP_HOST] then it will simply use the first one in your httpHosts array: $config->httpHosts = [ 'www.company.com', 'dev.company.com', 'localhost:8888' ]; If it just contains one host then it'll always use that one, regardless of what's in $_SERVER[HTTP_HOSTS] … $config->httpHosts = [ 'www.company.com' ]; If you do have the non-plural $config->httpHost present (like below), then it forces use of that hostname, rather than letting PW auto-detect from your httpHosts array. Though if there's only one host in your httpHosts array (like above) then of course the effect would be the same. $config->httpHost = 'www.company.com'; My best guess is that you either have $config->httpHost or httpHosts set with '127.0.0.1', or that you have httpHost/httpHosts undefined in your /site/config.php file. To fix it you need to add your www.host.tld to a $config->httpHosts array and preferably as the first item in it. If you do see a $config->httpHost (non-plural) in your config.php them I would remove it.
  6. @ttttim In my experience a 504 gateway timeout comes prior to PHP max_execution_time and may not even be related to it (?). Which is to say, I think it's a server timeout setting that is probably specified somewhere in Apache or prior, rather than PHP. But my experience with 504s is mostly limited to this server we are typing on, and in the case of this server, I will get a 504 timeout on a long running process and the 504 comes from the load balancer rather than the actual node that is running the script. So when a 504 occurs here, it just breaks the connection with the browser but the script continues running till it finishes, interestingly. I have no idea if your case is similar, but one thing I can suggest in your script is that you call PHP's set_time_limit(600); within your long-running loop to reset PHP's timer on each iteration (600=10 minutes, or a different time if it suits you), otherwise you likely will be subject to PHP's max_execution_time as well.
  7. @JerryDi I don't think there's a right answer as to what would be the best structure for your case. It really comes down to your needs, which I don't have enough familiarity with this to give an ideal answer. You'll be able to build your search for championships by club, player, etc., either way, as PW will make that simple. You can have any kind of parent/child relationship for those championships such as… /years/year-num/championship-name/ /clubs/club-name/championship-name/ …and so on. But another route to take (and what I might recommend here) would be to have a /championships/ parent and have all the championships under there, perhaps auto-sorted by year. Each with fields for "year", "club", "players", etc. /championships/championship-name/ And perhaps fields like "club" and "players" on each championship page would be page references to other pages setup in a similar structure: /clubs/club-name/ /players/player-name/ …and so on. Taking this route (where all championships share a common parent) may not be perfect for any one need, but will likely be a good fit for a diverse range of needs, a solid choice overall. So without knowing the details of your needs that's the route I'd probably take.
  8. @Manaus This is a case where you should do a 302 redirect $session->location($article->url); rather than render different articles at the same URL. Otherwise folks won't be able to accurately bookmark it, and it'll confuse search engines, so it'd be an SEO problem. But I'll assume you know that and you want to do it anyway. What Zeka mentioned above is a good way to go, and probably the one I'd choose. But here's also another option below. It assumes you have a "latest-article" template and it is used by the page /latest-article/. /site/templates/latest-article.php $article = $pages->findOne("parent=/articles, sort=-created"); if(!$article->id) wire404(); echo $article->render(); If you are using prepend/append template files, then you'd also want to check the box to disable them in Setup > Templates > latest-article > Files (tab).
  9. @Robin S @bernhard @teppo I would say it's less important to limit how many fields you create than it was before, but it's still worthwhile to make efficient use of fields for other reasons (at least for the way I work). But the technical reasons for doing so appear to be much less than before. If you look here at the performance numbers on a system with 1000 fields you can see that prior to lazy loading, it took 0.5167 ms (half second) to load the fields. This might sound reasonable, but note the fields were created with an automated script and not as diverse as they would be in a real environment, so I'd expect the numbers to be higher/slower in real life. After lazy loading that part of the boot process was reduce to 0.0062 ms. Even without lazy loading enabled, the field loading was reduced to 0.0322 ms (in that 1000 field environment) just due to the other optimizations made in support of lazy loading. So there's some question as to whether lazy loading is even necessary anymore now that everything else more optimized. But using less time and energy is always good thing, even if not felt on individual requests, small differences add up to significant numbers over thousands of requests. The way lazy loading works is that everything in the database table (for fields, templates, fieldgroups) still gets selected and loaded, but into an array rather than into objects. That data doesn't get loaded into and converted to actual Field (or Template, Fieldgroup) objects until that specific object is requested. TheTuningSpoon found that overhead came from actually creating and loading the objects rather than selecting them from the DB, and I was able to confirm that. But it also means that the more fields you have, the more memory they will consume. But the memory consumed by the raw field data is very little and I think you'd have to have many thousands of them for it to even be a consideration. Lazy loading fields don't change the way I use fields, at least. I like to have as few fields as necessary just because it's easier for me to keep track of, fewer things to remember when writing code, fewer things to manage during changes, etc. But if your workflow is like the one Bernhard describes above then that seems like a case where more fields would appear to be a benefit.
  10. This new main/master version has more than 220 commits, resolves more than 80 issues, adds numerous new features, performance improvements and optimizations, and consumes HALF the disk space of our previous release— https://processwire.com/blog/posts/pw-3.0.200/ I've just merged the dev branch to the master branch so this new version is available now. I will add the 3.0.200 tag (which should trigger packagist and others) over this weekend or Monday.
  11. @chrismac That error seems to indicate that you might potentially be running a very old version of ProcessWire 2.x (last updated 7 years ago). While the module (ProcessHannaCode) is designed for ProcessWire 3.x (the current one). That's the only explanation I can think of for that error message, as there is no "ProcessWire\WireData" in ProcessWire 2.x versions. The only way to resolve this is to remove the files that were installed, removing the /site/modules/ProcessHannaCode/ directory that was added. This has to be done by someone with access to the server files, such as your web developer or someone with FTP access to the server.
  12. @Matzn Your TestModuleChild.module is overriding the getModuleConfigInputfields() of the TestModule.module and replacing it. In PHP, if you want the parent method to run, then you need to either omit the method completely in your child class, or call the method parent::method() so that it will run (like what you are doing with your __construct method). What you are doing currently is replacing the method with one that has no code in it. What I think you are wanting is this in your TestModuleChild.module: public function getModuleConfigInputfields(InputfieldWrapper $inputfields) { parent::getModuleConfigInputfields($inputfields); } After doing the above, now it will inherit the code of the parent class. And after calling that parent::method() maybe you want to add another configuration setting to it, i.e. public function getModuleConfigInputfields(InputfieldWrapper $inputfields) { parent::getModuleConfigInputfields($inputfields); $f = $this->wire()->modules->get('InputfieldText'); $f->attr('name', 'test_field'); $f->label = 'Test field'; $f->val($this->test_field); $inputfields->add($f); } But if you don't want to add anything new to the getModuleConfigInputfields() then just leave the method out of your TestModuleChild.module completely, and it will inherit automatically. Also, module configuration data should be defined with runtime calls, so I recommend you remove this: public $field_1 = "parent module property 1"; and replace it with this in your __construct(): $this->set('field_1', 'parent module property 1'); I see you are using static getModuleInfo() methods in your classes. In cases where you've got one module extending another, unless the child module literally does an include() at the top of the parent module's file, then you should define your child module's info in a ModuleName.info.php file like I described in my previous message (including the 'requires' statement), and omit the getModuleInfo() static method. Otherwise, if PHP/PW happens to include() the child module before the parent module, you'll get a fatal class error. By using a separate ModuleName.info.php, PW can learn about the module without having to load the class file, and it can see from your 'requires' statement that it needs to load the parent module before your child module, ensuring no fatal errors. If you can't do this, or don't want to, then make sure your child module does an include() or require() of the parent module's file, somewhere before your "class TestModuleChild ...".
  13. @DrQuincy Yes, sorry, it should be "return $this->halt();" rather than just $this->halt(), I have updated my example. If you don't do a return then it'll still do the same thing (see below), but instead it'll continue executing your code in that file after the halt() call. What $this->halt(); does is tell the current request not to render any more files. So if you call $this->halt(); from your template file, then it's not going to include any further files specified to render afterwards. For instance, it will skip rendering your _main.php file (if you are using one). But everything else about the request will continue normally, so it does a normal shutdown, etc.
  14. @Matzn ProcessWire classes are just PHP classes, so there would be no difference. Note that I don't think you can have a class named "Parent" as I think that might be a reserved word in PHP. I wouldn't bother trying to do an external configuration class. Start with an internal getModuleConfigInputfields() method, and when all works, then consider moving it to an external one if needed. Make sure your module implements the ConfigurableModule interface, indicated at the top of the class. I also think maybe you shouldn't try to extend your Parent module/class and instead should just write another module that pulls from the Parent module what it needs. Module inheritance is useful in many situations but it's not clear to met that this is one of those situations, though I could be wrong. This is fine the way you are doing it, but note that your class "Child" need not extend "Parent" given the approach you are using. Your "Child" module could just extend WireData instead, and the code in your myMethode() would do exactly the same thing.
  15. @DrQuincy Is this from a template file? You could do this: echo "<p>An error occurred!</p>"; return $this->halt(); That halts the rendering of output but lets PW finish everything else in the request. Another option is to throw a WireException. This will also halt the request but allow PW to still shutdown. The response is an http 500 error. The error message will be displayed if in debug mode or if the user is logged in and a superuser. throw new WireException("An error occurred!"); Often times on the front end a fatal error is about a resource not available, and a 404 is the appropriate response. So you can do this: throw new Wire404Exception(); or this does the same thing (I prefer this shorter version): wire404(); Lastly, while the above are preferable, it's also okay to do an exit() or a die(), is shouldn't break anything at least.
  16. @Matzn Are you wanting a parent/child class relationship, or are parent and child modules separate modules where you want the child module to pull a value from the parent module? If you just want to pull a configuration value from "ParentModule" to use somewhere in "ChildModule" (or anywhere else) then you don't need to have a parent/child relationship between the modules and can instead just pull the value you need: $api_user = $modules->getConfig('ParentModule', 'api_user'); On the other hand, if you really do want a parent/child relationship between the module classes, and they will be two separate installed modules, then it is possible. Many Inputfield and Fieldtype modules use this approach. For instance, InputfieldCKEditor extends InputfieldTextarea, and InputfieldTextarea extends InputfieldText. The reason is that they all have similar configuration needs, as they are all inputs for text. InputfieldCKEditor builds upon the configuration of InputfieldTextarea and InputfieldTextarea builds upon the configuration of InputfieldText. When it's possible that someone might attempt to install the ChildModule without having first installed the ParentModule then it's recommended to keep your module-info in a separate php (or json) file like ModuleName.info.php, at least for the modules that require another (i.e. ChildModule requires ParentModule). This ensures that if ChildModule is on the file system, but ParentModule isn't, PW can identify the requirements for the ChildModule without having to load its class file. (If it loaded its class file, then it would result in an error since ChildModule extends ParentModule, and ParentModule isn't present, so that's why we want to avoid that). Let's say we've got this ParentModule: // ParentModule.module.php class ParentModule extends WireData implements Module, ConfigurableModule { public function __construct() { $this->set('api_user', ''); // establish default value parent::__construct(); } public function getModuleConfigInputfields(InputfieldWrapper $inputfields) { $f = $this->wire()->modules->get('InputfieldText'); $f->attr('name', 'api_user'); $f->label = 'API User'; $f->required = true; $f->val($this->get('api_user')); $inputfields->add($f); } } And it also has this ParentModule.info.php file to define module info. Since ParentModule doesn't extend another module, it could also be in a static getModuleInfo() method if you preferred it, but we'll stick to the file for this example: // ParentModule.info.php <?php namespace ProcessWire; $info = array( 'title' => 'Parent module', 'version' => 1, 'summary' => 'Parent module description', ); Here's a child module that extends ParentModule and also adds an "api_key" to the configuration: // ChildModule.module.php class ChildModule extends ParentModule implements Module, ConfigurableModule { public function __construct() { $this->set('api_key', ''); // default value parent::__construct(); } public function getModuleConfigInputfields(InputfieldWrapper $inputfields) { parent::getModuleConfigInputfields($inputfields); $f = $this->wire()->modules->get('InputfieldText'); $f->attr('name', 'api_key'); $f->label = 'API Key'; $f->required = true; $f->val($this->get('api_key')); $inputfields->add($f); } public function test() { $this->message("API user is $this->api_user and key is $this->api_key"); } } …and the ChildModule's info file is below. Note the "requires" that says it requires ParentModule: // ChildModule.info.php <?php namespace ProcessWire; $info = array( 'title' => 'Child module', 'version' => 1, 'summary' => 'Child module description', 'requires' => 'ParentModule', ); Zeka's example above is also a good one, but just adding my example as another variation.
  17. @cpx3 There's definitely something strange going on with that selector performance, so I'd still recommend that strategy of removing things from it (in the order mentioned) to identify the bottleneck. Once we know the bottleneck we can focus in on the particular field or fieldtype that is having the performance issue and hopefully find a solution. That's interesting that adding a "created>date_minim" helped, but it makes sense as it would just reduce the quantity in the set from which it has to match, so likely the bottleneck is still there. How many pages total are in this site?
  18. It's been a quiet week on the dev branch (mostly), and so this post will also be short. That's a good thing, as it means we are at a stage where there's no new major things to immediately fix or add. Assuming that remains the case, by next week at this time we should have 3.0.200 released on the main/master branch. In next week's post I plan to outline all that's changed since our last master version, 3.0.184, stay tuned and have a great weekend!
  19. @cpx3 First, make sure that the issue isn't that the selector is getting called repeatedly in a loop or something. Once you've confirmed that it's only getting called once per request, the next step is to identify what in the selector is making is slow (1200ms is slow). Remove the "id!=" from the selector, as that doesn't do anything. Update the order of the selector to the following. This is the order that I think represents the most likely bottlenecks towards the end, and the least likely towards the front, so it'll be easier to debug in this order. template=template-news, limit=5, sort=-created, checkbox_not_startpage=0, checkbox_not_startpage=0, select_countries=oesterreich, select_categories!=tipps|shortcuts, begin=(start_date=''), begin=(start_date<=today), ending=(end_date=''), ending=(end_date>=today) (Note that I've replaced your "end" with "ending" since "end" is a reserved word in PW, though it may not matter here.) Using your debugger (Tracy?) start removing parts of the selector from the end, until it starts performing fast. For instance, first try removing this from the selector: ending=(end_date=''), ending=(end_date>=today) Note what difference it makes, then remove this also: begin=(start_date=''), begin=(start_date<=today) and then this: select_categories!=tipps|shortcuts ...and so on until you get to "limit=5" and stop there (don't remove "limit=5"). Let me know what you find.
  20. @David Karich I was working on the snapshot module for awhile, then got sidetracked on another project and lost the momentum on it. Hopefully will return to this, though now that I've been away from it for awhile, I can see I was having a lot of fun developing it but am starting to question whether it's really that useful. The language translation export/import module is currently in development and a sponsor split the cost of development with me. It is currently fully functional and in client testing right now. The major features are built but there's still a few smaller things I want to finish developing before it is ready for production use. This one is pretty close to being finished though. @szabesz The control of types is still on my radar. Are you looking for it with nested repeaters or with depth repeaters? I think depth repeaters is where people were looking for it, but wanted to confirm. The background-color for repeater matrix items was implemented last year, and should be fully functional. Where do you see the hex codes show up, in the page editor? They shouldn't be, I've not seen it, and it's not been reported before as far as I know, but if it's something you are seeing (dev branch and latest RM) please let me know.
  21. This week's commits for ProcessWire 3.0.199 focus primarily in wrapping up several remaining reported issues in preparation for our master/main release version. So you can think of 3.0.199 as very close to a release candidate for the next master/main version. A few of the issues resolved this week were ones that had been around a long time, due to being difficult to reproduce, or issues that had been held off for awhile because they were going to take additional time to resolve. (See commit log for details). Having closed out a few of those older issues this week, I'm feeling good about where the dev branch is right now and think we're just about there. If you have a chance to test out the current dev branch (3.0.199), please let us know if you run into any issues. At least one person has asked about why we're not bumping the version to 3.1 (previously, or now). The reason is that all 200 versions of 3.x should be compatible with each other, enabling one to upgrade (or potentially downgrade) between the 3.x versions, without any drama. That's a good thing I think, and so I'm kind of proud that we are approaching version 3.0.200, which will hopefully be our next master. I'm sure we'll have a 3.1 at some point in time, but I'd like to keep on the 3.0.x track so long as upgrades remain drama free. Thanks, and have a great weekend!
  22. @theoretic Sounds like a fun project. If I understand correctly, you are doing a select to read the value, then incrementing the value in PHP, then writing the value. With concurrent requests doing that, there's always a gap between the read and the write, so you should expect that some of the requests are naturally going to collide, unless you use a different strategy. What you probably need instead is a single update query that does a "col=col+1" instead. Otherwise you'll have multiple requests reading a value (like the number "3"), incrementing it, then writing the same number "4" to the DB. So the final number would always be less than the number of requests sent. The reason being that some other request may have incremented the value in between the time another request read and then wrote the value, so they'd always be overwriting each other, writing the same "4" to the DB. If you need separate read/write queries, you'd need to obtain both a read and write lock to the table row you intend to update, before you even read the value. And you'd need to release the lock after you write the value. You'd also have to account for the cases where you cannot obtain a lock (due to being locked by another request), by having a retry mechanism. Without a retry mechanism, you'll also end up with some unaccounted for requests. A good example of the pattern you are trying to achieve is implemented in the SessionHandlerDB module. It has to obtain a read/write row lock and read the session values. Then at the end of the request, it has to write the session values, then release the row lock. That way concurrent requests in the same session can't overwrite each other's data. But it also means that concurrent requests are queued and have to wait in line for their turn to control the data. The same would be true in your test case. Lastly, pay attention to the http response code on the concurrent requests. Requests can be refused, especially if concurrent from the same session or IP. They can be refused by Apache or PW. So a request cannot count towards a total unless it returns a "200 OK" response code (this would be true for any concurrent testing of web requests whether w/PW or elsewhere).
  23. This week on the dev branch we've got a good mix of updates and issue resolutions, though not quite yet enough yet to bump the version number just yet. But here's a few highlights: There's a PR from Adrian committed which adds configurable columns for Selector fields. System update 20 was added which fixes the "created user" for several system pages. WireHttp was updated to support sending cookies in GET/POST requests powered by CURL. Lister was updated to recognize non-sortable fields, preventing unnecessary error messages. There were also 3 issue resolutions this week. We are getting down to the smaller stuff in terms of updates, which means it's about time to get that next master version out. I know I've been talking about it for awhile, but think we'll likely have one more dev branch version (3.0.199) and then it's looking like our 200th 3.x version will tentatively be the next master version (3.0.200). Thanks for reading, Happy Earth Day, and have a great weekend!
  24. ProcessWire 3.0.198 contains a mixture of new features and issue resolutions. Below are details on a few of the new features: Support was added for runtime page cache groups. This enables pages to be cached as a group—and just as importantly—uncached as a group. While it can be used by anybody, it was added primarily to add efficiency to $pages->findMany(), so that it can cache supporting pages (like parents and page references). Previously, it would have to load a fresh copy of each supporting page used by findMany() results (for every returned page) since findMany() used no in-memory caching. If it did cache in memory, then you could potentially run out of memory on large result sets, so that strategy was avoided. Consider the case of iterating over all pages returned by findMany() and outputting their URLs... that triggers load of all parent pages for each page in the result set. And without a memory cache, it meant it would have to do it for each page in the results. Following this week's updates, now it can cache these supporting pages for each chunk of 250 pages, offering potentially significant performance improvement in many cases, without creating excess memory usage or memory leaks. When the chunk of 250 result pages is released from memory (to make room for the next chunk), all the supporting pages (parents, page references, etc.) are also released from memory, but not before. Now findMany() can offer both memory efficiency and great performance. For as long as I can remember, ProcessWire has had an apparently undocumented feature for dependent select fields that enables you to have two page reference fields using selects (single, multiple or AsmSelect) where the selected value in one select changes the selectable options in the other select (Ajax powered). Think of "categories" and "subcategories" selects, for example, where your selection for "categories" changes what options are selectable in "subcategories". Part of the reason it's undocumented is that it is one of those features that is a little bit fragile, and didn't work in some instances, such as within Repeater items. That changed this week, as the feature has been updated so that it can also work in Repeater items too. The $pages->findRaw() method was updated with a new "nulls" option (per Adrian's request in #1553). If you enable this new "nulls" option, it will add placeholders in the return value with null values for any fields you requested that were not present on each matching page. This reflects how PW's database works, in that if a field has no value, PW removes it from the database entirely. Without the nulls option (the existing behavior), it retains the more compact return values, which omit non present values completely. For example, consider the following: $items = $pages->findRaw("template=user, fields=email|first_name|last_name"); If a row in the result set had no "first_name" or "last_name" populated, then it would not appear in the that row of the return value at all... [ "email": "ryan@processwire.com" ] By specifying the "nulls" option, it will still include placeholders for field values not present in the database, and these will have a value of null: $items = $pages->findRaw("template=user, nulls=1, fields=email|first_name|last_name"); [ "email": "ryan@processwire.com", "first_name": null, "last_name": null ] By the way, if you don't specify which fields you want to get (which is the same as saying "get all") then adding the nulls option makes it provide placeholders for all fields used by the page's template. As you might expect, without the nulls option, it includes only populated fields. Also included in 3.0.198 are 7 issue fixes, most of which are visible in the dev branch commits log. That's all for this week. Thanks for reading this update and have a great weekend!
  25. I figure this is an off topic board among friends here (like our pub, or a real one) and it’s okay to write with honesty and engage in spirited or sometimes heated conversation. So just want to be clear that I like and respect @MoritzLost and value his opinions, even if I don’t agree with all of them. We will all have a diversity of views and everyone should feel free to share them, and likewise others should feel free to question those or state their own, which is what I’m trying to do. But I’m glad MoritzLost shares his opinions here. Plus, a little controversy also helps to engage the community, and drags me out of the code for a bit, so I can’t fault anyone for that. Once I can state my thoughts, I carry no concerns, but thought I should defend the things that deserved defending, as I always should. As a caretaker of this project, part of my responsibility to add my honest point of view to a conversation like this, especially when something is posted where I don’t fully agree. I think many in our community know the subjectivity of statements here (whether OP’s, mine, or another’s), but an equal number may not, as this is a public board. So some counterpoint or back-and-forth is not only clarifying to the larger audience, but also useful, as we explore different facets of it all, and lead to the most important takeaways. I appreciate that MoritzLost continues to defend his point of view on parts, despite my own defense or heated questioning of those parts. It helps me to better understand and know which are the parts that he thinks are most important and deserve the attention. We obviously don’t have the resources to pursue everything Craft does, so narrowing in on the most important parts—the meat of it—is helpful here. I’m traveling right now so can’t participate as much as I’d like to at the moment but just didn’t want MoritzLost or anyone else to think I was angry or something. Likewise I didn’t want anyone else to think they had to moderate themselves either. When I’m among friends I feel comfortable to express and be honest, and so should you. If you get a heated reply from me it’s because I care about it and value your opinion. I’ll spend more time reading everything when I get back, but I can see already it’s a good and helpful discussion.
×
×
  • Create New...