Jump to content

ryan

Administrators
 View Profile  See their activity

  • Posts

    17,204

  • Joined

  • Days Won

    1,688

ryan last won the day on February 21

ryan had the most liked content!

58 Followers

See all followers

Contact Methods

  • Website URL
    https://processwire.com

Profile Information

  • Gender
    Male
  • Location
    Atlanta, GA

Recent Profile Visitors

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

ryan's Achievements

Hero Member

Hero Member (6/6)

27.8k

Reputation

212

Community Answers

  1. ryan started following New blog: All about custom page classes in ProcessWire and New blog: Handling photo heavy sites in development
  2. ryan
    ProcessWire and photo-heavy sites go hand-in-hand. But these sites can also present development challenges, especially when cloning a large site. This post goes into detail about techniques you can use to keep lightweight development sites without all the photo/image overhead. https://processwire.com/blog/posts/developing-photo-heavy-sites/
      • 13
      • Like
  3. ryan
    @maximus Thanks for updating it. I had tried to do so a week or two ago and there were various variables involved in it that I couldn't figure out the source of, so ended up adding it to some version history log, thinking maybe it was pulling from that, but apparently it wasn't. It looks like you replaced the variables with the actual version, which is much simpler.
  4. ryan
    @gebeer That's an excellent summary, thanks! On the core-patterns one, the 'getExcerpt' example probably isn't ideal because it's only returning an excerpt if output formatting is on, otherwise it's returning the entire 'body' field with tags stripped out, which isn't an 'excerpt'. Usually a 'body' field is HTML (TinyMCE, CKE, etc.), so the formatted version would be the same as the unformatted version, unless there's some other formatters being applied on top of it, like TextformatterVideoEmbed, etc. There's an example of a getExcerpt() in the blog post that I think might work better, though I'm sure there are even better examples possible. In the same file, under API wire access, it says that pages() would not work in a Page class. But actually it would work just fine, so long as functions API is enabled. But what's preferable is $this->wire()->pages because it would be guaranteed to be tied to the correct instance (just in case multi-instance, even if rare). For calls like $this->wire('sanitizer') (where API var is in quotes) I'd suggest $this->wire()->sanitizer instead, just because the IDE will know that it's referring to the Sanitizer class, whereas if 'sanitizer' is in quotes then the IDE won't know, or at least it will have to do a lot more work to know. The same goes for any API variable. Lastly, do you think it could link to the blog post also, since that's the source for some of it -- It might help for folks looking for additional info? Thanks!
  5. ryan
    @Ivan Gretsky I'm always a little reluctant to make a blanket statement like "avoid markup in page classes", but I'm referring to what I think works best with the projects I work on. The files in /site/templates/ are the view layer, as nearly all code in there is aimed at generating markup/output. Even if something isn't directly generating markup, it's still finding and preparing things for output. Most markup comes from "partials", which are files that I put in /site/templates/parts/, or if exclusive to a particular template, then /site/templates/[template]/. And then I either include() them, or files()->render() them from the site's template files. I primarily use Markup Regions. The _main.php establishes the base markup: <?php namespace ProcessWire; /** @var Page $page **/ ?><!DOCTYPE html> <html> <head id="html-head"> <?php include('./parts/html-head.php');?> </head> <body id="html-body"> <header id="header"> <?php include('./parts/header.php');?> </header> <h1 id="headline"><?=$page->title?></h1> <main id="content"> <?=$page->body?> </main> <aside id="sidebar" pw-optional> </aside> <footer id="footer"> <?php include('./parts/footer.php');?> </footer> </body> </html> Below is a template file for the /products/ page which lists product pages, supports pagination, and uses URL segments for sorting: <?php namespace ProcessWire; // products.php /** @var ProductsPage|CategoryPage $page */ $products = findProducts($page); $body = input()->pageNum === 1 ? $page->body : ''; $headline = $page->get('headline|title'); ?> <h1 id="headline"><?=$headline?></h1> <main id="content"> <?=$body?> <?php include('./parts/sorts.php'); // no expects ?> <?php include('./parts/products-list.php'); // expects $products ?> </main> <aside id="sidebar"> <?php include('./parts/categories-list.php'); // no expects ?> </aside> The category template file works exactly the same way, except that it lists products for the category rather than listing all products. The same code works either way, so "category.php" just includes "products.php": <?php namespace ProcessWire; // category.php include('./products.php'); There's that findProducts() function above in the products.php template file -- I usually have helper functions in a /site/templates/_func.php, /site/templates/_products.php, or /site/templates/products/func.php (assuming exclusive for "products"). Another place would be for the ProductsPage and CategoryPage to have findProducts() methods, but usually I don't want the page classes getting involved with detecting stuff about the current request (sort, pageNum, etc.) so like these in a simple function library file: <?php namespace ProcessWire; // file site/templates/_func.php included by _init.php function getSorts(): array { return [ 'name' => 'A-Z', '-name' => 'Z-A', 'price' => 'Price (low-high)', '-price' => 'Price (high-low)', 'created' => 'Date added (oldest)', '-created' => 'Date added (newest)' ]; } function getSort(): string { $sorts = getSorts(); $sort = input()->urlSegment('sort-(*)'); if(empty($sort)) $sort = 'name'; if(!isset($sorts[$sort])) wire404('Invalid sort'); return $sort; } function findProducts($page, $limit = 20): PageArray { $sort = getSort(); $find = "template=product, sort=$sort, limit=$limit"; if($page instanceof CategoryPage) $find .= ", categories=$page"; return pages()->find($find); } Here's an example of a ./parts/products-list.php file: <?php namespace ProcessWire; // file: parts/products-list.php /** @var PageArray|ProductPage[] $products */ $subhead = $products->getPaginationStr('Products'); $pagination = files()->render('parts/pagination.php', [ 'items' => $products ]); ?> <h3><?=$subhead?></h3> <?=$pagination?> <ul class="products-list"> <?php foreach($products as $product): ? <?php include('./parts/products-item.php'); // expects $product ?> <?php endforeach; ?> </ul> And the parts/products-item.php, though in reality there would likely be more to it: <?php namespace ProcessWire; // file: parts/products-item.php /** @var ProductPage $product */ ?> <li class="products-item"> <h3><?=$product->title?></h3> <p><?=$product->summary?></p> <p><a href="<?=$product->url?>">View Details</a></p> </li> To complete it, here's the parts/sorts.php file: <?php namespace ProcessWire; // file: parts/sorts.php $currentSort = getSort(); $url = page()->url; $sorts = []; foreach(getSorts() as $sort => $label) { if($sort != $currentSort) $label = "<a href='{$url}sort-$sort/'>$label</a>"; $sorts[] = $label; } echo "<p class='sorts'>Sort by: " . implode(' / ', $sorts) . "</p>"; If I start needing to output products in more places in the site, then I'll usually do fewer include()'s and move the rendering to dedicated functions. That way these things render in their own variable namespace and don't bleed variables or overwrite variables in the main rendering. So this would also go in that _func.php (or _products.php or ./products/func.php) mentioned above, and the include() calls in template fiels would be replaced with render...() calls: function renderProducts(PageArray $products): string { return files()->render('parts/products-list.php', [ 'products' => $products ]); } function renderCategories(): string { return files()->render('parts/categories-list.php'); } function renderPagination(PageArray $items) { return files()->render('parts/pagination.php', [ 'items' => $items ]); } So if using render() functions then the <main> with the include('./parts/products-list.php'); would get replaced with this: <main id="content"> <?=$body?> <?=renderProducts($products)?> </main> Ah yes, I hadn't thought about that in a long time. I can't remember if that was implemented yet or not. I'll find out. If not yet implemented I'll have to implement it, it should be fairly simple.
  6. ryan
    Everything you need to know about custom page classes, from beginner to advanced. You'll find time saving tips and tricks, pitfalls, best practices, and plenty of examples too— https://processwire.com/blog/posts/custom-page-classes/
  7. ryan
    Included are more than 70 issue fixes and 175 commits. Here we’ll zoom in on the numerous new features and improvements to the core for one of our best new versions yet! https://processwire.com/blog/posts/pw-3.0.255/
  8. ryan
    Today I’ve merged the dev branch to the main/master branch in preparation for our next official tagged version, which is likely to be 3.0.255. I’ll likely git tag it with the version number early next week. This doesn’t mean that work on the next main/master version is complete. Just that no new issues have appeared that would warrant delaying it any longer. So while there’s still work to do, we’re also at a good point to start getting these updates on the main/master branch. As before, if you run into any issues after upgrading, please report them in the processwire-issues repo. I’ll compile and post a list of all that’s new in 3.0.255+ relative to 3.0.246 within the next week or two so stay tuned. There have been some really nice sites showing up in our sites directory lately. Thank you for those that have been submitting new ProcessWire-powered sites, and please keep it up! It’s great to see such awesome web design and development work.
  9. ryan
    @szabesz Thanks, I was able to duplicate that also. I couldn't figure out how to fix it, but @diogo had a look and came up with a solution. It should be on the dev branch now. Please let me know if you still run into the issue.
  10. ryan
    @thei Glad you got it working. It should be possible to use an array for this, but I might be forgetting something about it, as I think it's been a long time since I used one for this. In any case, it's definitely better to use a WireData object (or one derived from it) because ProcessWire can track changes to the properties in the object. Whereas there's no change tracking built into an array.
  11. ryan
    Happy new year! I’m focused right now on getting our next main/master version out, hopefully next week. I’m looking for anything that worked in 3.0.246 but doesn’t in the current dev branch. After this week's commits, I’m not aware of anything remaining that fits that criteria, but if anyone knows of anything please let me know. In addition, if you are aware of any remaining issues with with PHP 8.4 or 8.5 (deprecation notices, etc.) please let me know. In either case, the best place to report is in the processwire-issues repo on GitHub. If it’s something that’s already been reported, then please bump the issue by replying to “bump” to it (or whatever you’d like). Thanks and have a great weekend!
  12. ryan
    @thei I think the issue may be that the 'data' column isn't used here, and ProcessWire wants you to use it. So you could perhaps use 'data' as your "date_from" and then add another column called "to" or something, and use that as your "date_to". The only methods that would need to know about "data" and "to" would be those that communicate with the database: getDatabaseSchema(), wakeupValue() and sleepValue(). Everywhere else can refer to date_from and date_to. The wakeupValue would convert "data" and "to" to "date_from" and "date_to", while the sleepValue() would convert "date_from" to "data" and "date_to" to "to" (or whatever column names you decide to use). Example of the Fieldtype portion below: public function getBlankValue(Page $page, Field $field) { return [ 'date_from' => '', 'date_to' => '' ]; } public function getDatabaseSchema(Field $field) : array { $schema = parent::getDatabaseSchema($field); $schema['data'] = 'date default null'; // date_from $schema['to'] = 'date default null'; // date_to $schema['keys']['data'] = 'KEY data (`data`, `to`)'; $schema['keys']['to'] = 'KEY `to` (`to`)'; return $schema; } public function ___sleepValue(Page $page, Field $field, $value) { $value = $this->sanitizeValue($page, $field, $value); // store blank as null in DB if(empty($value['date_from'])) $value['date_from'] = null; if(empty($value['date_to'])) $value['date_to'] = null; // return value ready to store in DB return [ 'data' => $value['date_from'], 'to' => $value['date_to'] ]; } public function ___wakeupValue(Page $page, Field $field, $value) { if(!is_array($value)) return $this->getBlankValue($page, $field); // return value ready for $page->fieldName return [ 'date_from' => "$value[data]", 'date_to' => "$value[to]" ]; } public function sanitizeValue(Page $page, Field $field, $value) { if(!is_array($value)) $value = []; $value = array_merge($this->getBlankValue($page, $field), $value); $dateFrom = $value['date_from']; if($dateFrom) $dateFrom = wireDate('Y-m-d', $dateFrom); $dateTo = $value['date_to']; if($dateTo) $dateTo = wireDate('Y-m-d', $dateTo); return [ 'date_from' => $dateFrom, 'date_to' => $dateTo ]; } Next, I don't think your Inputfield processInput() method will work as-is, so I'd suggest changing it to something like this: public function ___processInput(WireInputData $input) { $value = [ 'date_from' => '', 'date_to' => '' ]; foreach(array_keys($value) as $key) { $date = $input->get($key); $value[$key] = $date ? wireDate('Y-m-d', $date) : ''; } $this->val($value); return $this; } Once you've got it all working, you might consider changing the array value to a WireData value. That will make it so that you only ever have to define the date_from/date_to array once, and it can sanitize itself rather than these other methods.
  13. ryan
    @FireWire I see it says Resolved now, but did you find out how it happened? I looked at the moderation log for the topic and there's no entry where anyone hid or locked the topic. Though I do see an entry where Netcarver fixed the issue. So I'm wondering what broke it in the first place? Maybe a side effect from the recent forum upgrade is the only thing I can guess so far.
  14. ryan
    I hope that you all had a nice winter holiday (Christmas, etc.) or are still on holiday till the new year. Not a lot to report this week since I’ve been on holiday too, but we finally launched that site that’s been keeping me busy for the last few weeks, so I’ll hopefully be spending a lot more time in the core this coming week. I'll get the site posted to the sites directory once some more of the post-launch details are taken care of. One thing I learned in launching that site is that Markup File Regions work great during development, but not so great on a busy site (at least a site using Amazon’s EFS file system, which is very slow). I ran into all sorts of strange issues so ended up converting the file regions back to regular old static CSS and JS files, and then everything ran smoothly again. So as solid as the file regions are during development, they will need more work before I use or recommend them in production. That’s the way it goes with developing new stuff sometimes. There is however a pretty nice improvement to Markup Regions committed this week though. Prior there were some limitations as to what could populate what. Typically output before the <html> (i.e. from template files) populated into output that comes after the <html> (i.e. a _main.php file). But now it is possible for the population of content to go in either direction. Further, more nested elements can also populate less nested (or non-nested) elements. It’s a little hard to explain, but basically, you don’t have to think too much about when and where you can populate things as Markup Regions will figure it out in the final output. This makes it even easier to use and hopefully more foolproof than before. Thanks for reading and have a great weekend!
      • 22
      • Like
      • Thanks
  15. ryan
    There aren’t any core updates to report this week, but that’s because I’ve been throughly wrapped up in a client project using ProcessWire (the same one I’ve been busy with the last couple weeks). When it came time to decide which version of ProcessWire to use when this project launches next week, there was no question in my mind about using the latest dev version. It’s very solid. I upgraded their existing site (using 3.0.229) to it in preparation for the new site, and of course there were no hiccups or glitches. But it did make me think the current dev branch really belongs on the main branch. So I think that as soon as we wrap this project up, I’d like to get a new main/master branch version ready by or before the end of the year, so that’s the goal. Lately there's been a real increase in the number of new sites posted to our Showcase, which is great to see! Some amazing work coming in. As always, If you have sites you've recently launched or soon will, please add them to the sites directory. Thanks and have a great weekend and happy holidays!
  16. ryan
    This week the dev branch core version has been bumped to 3.0.254. Relative to 3.0.253 this version contains 14 commits with around 10 bug fixes and 5 feature additions. The biggest addition is Markup File Regions, which I’ve used literally every day since adding the feature two weeks ago. Fingers crossed, but I haven’t had to fix anything or make any adjustments to it so far, so it’s been very stable and reliable. I’m currently working on a client project (collaborating with Pete, Diogo and Jan P.) and that’s kept me busy the last 2-3 weeks, and likely will for a couple more. So there aren’t likely to be a lot of commits to the core during that time, but I’ll be very ProcessWire focused for sure. Working on projects using ProcessWire (as opposed to just working on ProcessWire) has always been key. But I’ve also been wanting to get the next main/master version out as soon as possible (as I’ve mentioned a couple times recently), so will be trying to do both. Thanks for reading and have a great weekend!
×
×
  • Create New...