Leaderboard
Popular Content
Showing content with the highest reputation on 11/16/2024 in all areas
-
This week most of the core dev branch commits are related to minor fixes and improvements. While last week we added a new $page->preload() method, I’m going to avoid more major additions or features so that we’re not creating more things that need lots of testing. For that reason, the commits over the next weeks or month will be similar to those from this week, so that we can get a new main/master version out as soon as possible. I was just looking at the date of our last master version (3.0.229) and see that it’s been more than a year! It feels like it’s been 3 months to me — time sure does fly! Seeing how long it’s been definitely motivates me to not wait too much longer on this next main version. The current dev branch fixes and adds quite a few things relative to 3.0.229 as well, so I think of it as being the more stable version at this point… a good sign it’s about time for a new release version. Thanks for reading and have a great weekend!7 points
-
This week on the dev branch, we have a new $page->preload() method that enables you to preload multiple fields in one query (in this GitHub commit). This is kind of like what the autojoin option does (when configured with a field), or what the $pages->findJoin() method does, but with one big difference. Those options happen as part of the page loading process. Whereas $page->preload() can be applied to a page that has already loaded. Here’s one example where you might find this useful. Say you have a page living at /products/product/ and it has a hundred fields. At the top of your template file that renders the page, you could have a $page->preload(‘field1’, ‘field2’, ‘field3’); to preload all those fields before outputting them. This enables you to load field1, field2 and field3 in 1 query rather than 3. On your first call to $page->field1 it won’t trigger a load from the database and instead will return the value that has already been preloaded. You can also call $page->preload(); without any arguments, and it will preload ALL the supported fields for the page. In reality, ProcessWire is already pretty quick with loading fields, so you probably won’t benefit from preloading until the scale is quite large. While developing this, I was testing by iterating 500 pages and accessing 50 different fields from each. Without preload this took 12 seconds. With preload it took 6 seconds. So for this particular case, preloading cut the time in half. I’m not a query counter, as very often lots of simple DB queries are faster than a single big query, but I’ll mention that it also reduced the quantity of database queries by more than a factor of 10. For this large scale case, that meant more than 20000 queries down to well under 2000. Like with autojoin, there are some limitations with preloading. It supports primarily Fieldtypes that use the core loading mechanism. Some Fieldtypes (especially non-core) override this, and preload() skips over those fields. It also skips over most FieldtypeMulti (multi-row fields), but FieldtypePage is supported when used with Page fields that carry one value. Multi-value can be enabled for testing with an option you’ll find in the function $options, but like autojoin, is limited by MySQL’s group_concat limit. By default that limit is 1024, which supports 140-170 page reference values in a given page field. That's quite a lot, but I don't want to assume folks won't go over that, so it's disabled by default. I’m guessing that most won’t need the preload() function, but a few might really benefit from it, especially at larger scale. So I think it’s a worthwhile addition to the core, and another method that answers a need that may arise as an installation grows, further supporting ProcessWire’s ability to scale up as needs do. Though consider it experimental and "work in progress" at the moment, as we’ll need to do more testing to make sure it is fully stable in a broader range of situations, and further improvements are likely. Special thanks to @tuomassalo at Avoine who came up with the idea for preload() and helped me to get started developing it. Last week I told you how Pete, Jan and I met up in Holland. I also wanted to mention, a couple weeks ago, right before I left for Amsterdam, Oliver from @update AG (update.ch) in Zürich, Switzerland sent me a DM saying that he was in my neighborhood, so we got together for coffee near my house. They’ve been using ProcessWire at Update AG almost as long as PW has been open source, so it was good to meet another long time ProcessWire user, and a nice coincidence that he was in the neighborhood. It’s always great to meet ProcessWire users in person and I hope to meet more of you in the future as well. Thank you for reading and have a great weekend!2 points
-
FIXED! The error was because of a module I have developed 🤣 I've been coding for 14 hours and can't believe I missed it...well I can haha!1 point
-
I’ve had a great experience with Vultr, first as the data center for some sites I hosted via CloudWays, and more recently (since Cloudways was bought by D.O.) directly with Vultr. I absolutely recommend their “Vultr Cloud Compute” (shared-CPU VPSs) — especially the “high performance” and “high frequency” offerings starting at $6/month. In fact, I’ve found the absolute base-level “high frequency” choice is more than adequate to host five small PW sites (single “wire” folder, multiple “site” folders): 1 vCPU (3GHz+ Intel Xeon), 1 GB RAM, 32 GB NVMe SSD, 1 TB bandwidth They give you a choice of many OSs (including CentOS 9 and 10, though I use Debian 12) and many data centers worldwide. For my niche sites with visitors from around the globe, I’ve found it practical to set up one server locally for development and data entry. Whenever I’m ready to push a code change or new postings/pages, I make a (nearly free) snapshot backup of the staging server, and restore it to a half-dozen strategically chosen server sites (at $6/each): Amsterdam, Seoul, Atlanta — you get the idea). I have set up Cloudflare to handle the load balancing geographically. If the CPU and bandwidth are adequate but you need more drive space, they offer S3-compatible object storage or inexpensive regular block storage. Or if you’re a high-traffic site you can of course up the RAM, CPU, bandwidth, and internal SSD specs. The usual background applies: I have no affiliation with Vultr, I’ve just been happily hosting with them for three years. I do recommend that you choose either “high frequency” (if speed and a little extra drive space are more important) or “high performance” (if you want more bandwidth and are willing to trade a little drive space and speed for it), rather than “regular performance,” which felt surprisingly slower to me when I set up parallel systems for comparison. https://www.vultr.com/pricing/#cloud-compute/ https://www.vultr.com/features/datacenter-locations/1 point
-
Have a look at URL hooks! https://processwire.com/blog/posts/pw-3.0.173/ Oh, and welcome to the forum 😉1 point
-
Find yourself a great dev environment you understand and can use to create a new ProcessWire instance super easy. This is key. Based on what I saw the most complicated part seems to be the registration/and what follows afterwards (which I of course can't see). You need to find out if you can do this with PHP and PW on your own, with some community modules or the LoginRegisterPro module from Ryan. Everything else seems to be basic content with an advanced structure. Maybe some specials for logged in users but this should be quite easy to do the moment you have that registration part set up. Depending on how fit you are with programmig and PHP a little crash & burn session over the weekend should be a great starter for you to find the issues and questions you need to have answered to get your site moved to ProcessWire. I'm not a programmer, still I can do a lot. Sure, I need LoginRegisterPro and have to ask questions here and there, but ProcessWire is still the easiest tool I ever used for that. Nowadays maybe even use Cursor, Supermaven, Claude Sonnet, and other AI tools to assist you. Feed them the ProcessWire docs and you can get a great headstart. In the meantime: we are here and happy to help1 point
-
Well... those that live on/work with the dev branch have had quite more releases already. 😊1 point
-
Hi Natalie, welcome to the PW forum. I would start setting up a local development env (like ddev) with a clean PW installation and a blank template. Then I would decide on a output strategy, like delayed output. Next I would create the HTML template using the look of your old site with some basic pages and the nav menu. Once that is done, I would try to implement one dynamic page (e.g. member login area) from your old site and see how for you get. If you hit a wall on your journey, come back in the forum and ask for guidance. The community here is very kind and can help you on your way. Thats how I started with PW. After the first implementation with just the PW API and basic concepts, I did a rewrite using some of the more advanced techniques like implementing the Latte template engine and PageClasses. But my first setup was just procedural PHP code organized in functions stored in helper files and basic PW PHP template files using the great PW API. That get‘s you started quickly, which I think is more important than trying to get the most sophisticated features implemented right from the beginning. I tend to go with release soon and iterate fast approach most of the times. Just my two cents. Cheers cwsoft1 point
-
1 point