Violet

I too am grappling with this issue for an image gallery page that I'm trying to paginate. My template file contains code for groups of things in general (e.g. blogroll), laid out in a similar way to the desired gallery page. The blogroll is working just fine so I don't want to make a whole different file just for the image gallery, I just want to use different logic within the same template. I suppose I should clarify: my image-gallery template file is very short: just a php include of the blogroll template. Inside the blogroll template I have different logic for image gallery versus blogroll where applicable. I do have the page template set to allow pagination in the admin side. I like the code solutions presented previously in the thread that involve piggybacking onto the MarkupPagerNav module, since I'm using pagination for my blogroll anyway. ? My question is, I'm wondering if there is (or could one day be) a function in the ProcessWire API that as a one line command, converts images on a page to a (temporary) page array, each element of which contains one image? ?The idea being that the resultant page array could be used directly for pagination purposes just like any other page array, which is handy for image gallery situations such as this. It seems like it's a common issue people are facing. For now and for my site's situation, even for the solutions that piggyback off MarkupPagerNav, it seems like a bunch of extra code to add to a template that is otherwise working fine (I mean for blogroll purposes it's working perfectly). I really like the idea of passing a page array directly to MarkupPagerNav (with limit in the selector, I mean) without keeping track of total, start, and slice. So for now I'll probably instead from the admin office make a bunch of child pages from that page, each containing one image, and get the desired page array from that so I can handle the pagination with the same type of code as I've used for my blogroll.

This is an update about how it's been running blog sites using ProcessWire. I hope it's OK for me to post in this category even though I've already showcased my sites awhile back. I thought it would be helpful for people to get a feel for what it's like to use ProcessWire on an ongoing basis for blogging. Often people talk about the development of a site, but it's not quite as often that we hear about the ongoing running of a PW site and how the PW API influences that, which is what I'll cover here. As background, we at The GrayFly Group own and run the blogs goodkidsclothes.com and flipfall.com. The development of these PW sites has been covered in a showcase thread for GoodKidsClothes and another for FlipFall. Here are some of the unique experiences I've had running these two sites. "Running" covers everything from coding and making modifications to the templates, to writing our articles, to interacting with ad partners or with others seeking us out for something related to one of those sites. So this is a different experience from agencies who develop for others; we develop for ourselves. As background, the main traffic to the websites comes from organic search results. Income from sites is from affiliate marketing and advertisements. GoodKidsClothes PW experience: "to think it is to do it." For GoodKidsClothes.com, one of the things we noticed was that if we could think it, we could do it, thanks to the easy-to-use PW API. The need for a change Here is a concrete example of what I mean: we noticed that many people would enter the site on an older article (e.g. via a search result). However, we continually put out a lot of time-sensitive information, e.g. a style guide, a piece of news relating to a change in a children's clothing company, etc. I didn't want people to miss out on this, yet many were, because after reading their entry page, they'd leave. They had no idea (unless they clicked on the link to home page) that there was another article that could be of value to them. All too often, by the time people learned about that new article via search results, they'd be too late for the news to be relevant - in fact, it wouldn't even be the newest article anymore by that point. The solution So, using the PW API, we modified the article template so that if someone was reading any article that was not the most recent article, then at the end of what they're reading, they'd see a small section highlighting the most recent article. Here is a screenshot: As you can see above, our newest article is highlighted immediately below the article they're reading, unless of course they are already reading the newest article. In the case shown above, the newest article (recipe-related) did not happen to be time-sensitive, but in most cases that article would be time-sensitive, so that's why we made this change. To make the change we simply used the PW API to query what the latest article was and store its identity in a variable - those sorts of queries we set up in _init.php. Then we modified the article template such that if the current page was not the latest article, to include the featured box that you see above. Another need for a change You'll also notice links in boxes above and below where the featured article box is. These are ads (they blend OK right?!) These ads brought another problem to our attention: we'd put the ads blocks on all articles equally. However, in the case of the most recent article, often the most recent article would usually have a time-sensitive offer or some other call to action e.g. signing up for our newsletter (well, not in the case of the recipe article above, but in most cases the latest article would have something we prefer the reader to do). We didn't then want our readers to get distracted by the ads and either leave the site, or click on an ad and click away from the site, instead of doing whatever the call to action is. The solution Again using the ProcessWire API, we modified the "article" template so that there was conditional logic on the ads: if the current page is not the latest article, include the ad code (otherwise no ads). This mean no ads were seen on the most recent article, allowing for less distractions to the reader on time-sensitive articles and more likelihood of them following through on the call to action. Conclusion for GoodKidsClothes We were able to make all these changes within minutes of thinking of them! In-house, without a ton of knowledge of programming, thanks to the awesome ProcessWire API. We actually made all those changes live, i.e. going in there and making changes to the code of the site as its running live. Yes, we had backups of the entire site and we always first save a copy of the template file under a different name (usually prefixing it with OLD_ ) before modifying the live version. This is how helpful ProcessWire is. We can make changes that benefit our site and make them in-house as we think of them. If this was done under some other CMS, we would be unable to make those changes without either a) hiring a developer or b) training up in whatever the other CMS is to make the changes in-house. Either way, it would take considerably more time to do anything. So, despite not having a formal programming background, we now have a very "nimble" site that we can adapt as needed to changes that we desire, within minutes of thinking of the change we need, with only needing to know a little PHP, html, and CSS, just the very basics, and looking up the PW API. FlipFall PW experience: "the answer is yes." In the case of FlipFall, there have been times when a potential ad partner asks a question like "can you put different ads on different categories?" or other things. Sometimes they are questions I ask myself of the website "Can we do A/B testing of different ads; i.e. show a certain ad block 50% of the time totally randomly and another ad block the other 50% of the time?" "How about ads from this company some of the time and a different company other times?" The answer is always "yes." Coming from other CMS's (that I used but did not program with) I used to brace myself a bit if I saw an email that asked "Can you....?" but now thanks to ProcessWire I don't have that bracing reaction any more. So long as I can think of a way to do it (and so far I always have, thanks to the PW API), I can say "Yes we can." More to the point, I can actually say "Yes, we can make those changes in-house within [whatever brief timeframe I think it will be]" instead of having to be vague about timeframes because of needing a developer. So I no longer worry about "Can you ...?" questions because the answer is yes. Overall conclusions ProcessWire is a superb CMS for those who own and run a site. The PW API makes it easy to make changes to the look and functionality of the site as needed. Such modifications wouldn't easily be possible on alternative CMS's that are heavily "theme-based".

Thank you @Robin Sand @tpr for taking the time to respond. I tried Robin's solution and worked beautifully thanks. It's working well, I've enabled that option in one of my sites and I'm about to do it for all of them. Even though I had gone through the field options in the body field, I somehow missed the "Counter" option! ? [facepalm moment] I really appreciate this. I had no idea this feature was already in ProcessWire! So, no need to add it to wish list. Sorry! I will mark the thread as solved, and maybe a moderator would be kind enough to move it out of wishlist category... or is that something I can do myself? Anyway thank you both for solving the problem and hopefully anyone searching the forums will now see that this feature already exists.

There are a couple of small features that I feel are needed in ProcessWire for the serious blogger. One of these is a word count in CK Editor. When writing the body of a blog post, it can be a little frustrating not to know the current word count. (If you're not sure what I mean, take a look at this online editor just as an example https://html5-editor.net/ - the ongoing word count is displayed at the bottom right.) That sort of feature is built into the core of many other blogging platforms. Writing the blog post directly in the editor is important, because if writing it in an Office program and copy-pasting it into the body field in Processwire, we can wind up with unwanted stuff in the html (like the font used, etc) - plus, it's not an elegant solution. Likewise, I find it frustrating doing what I currently do, which is writing in CK Editor and having to copy-paste into an Office program every so often, just to ascertain the word count. Why is word count so important to bloggers? When working with brands. When writing an article that's a sponsored post, usually the brand and the blogger have agreed upon a word count (e.g. 500+ words). That's quite a typical situation in the field, yet right now the CK Editor gives the author no info about the word count. For SEO purposes for their own articles. The blogger may have a certain word count they are aiming for in an article, even if they are not working with a brand. Short articles don't always do as well on Google search results, so the blogger might be looking to create a longer article. Writing without an ongoing displayed word count is rather hard on the process of writing. I can't describe it very well, but it really is hard. So, the ability to display the ongoing word count (to the author while writing) in the CK Editor is a feature I'd like to propose for the ProcessWire wish list.

Thanks for your input and for taking the time to respond. I had no problems with a sub-directory in a WP site. I didn't have to do anything with WP's .htaccess rules first. This was the case for all our WP sites we transferred to ProcessWire, and also the case for a different WP site we had that had an OpenCart store attached to it in a subdirectory e.g. thesite.com/store. In case it is of relevance, all the installs I did (of Processwire, Wordpress, anything) were via Softaculous. Hmmm. Would the fact that flipfall.com/stagingfoldername had its own .htaccess file (i.e. the Processwire .htaccess) and its own index page have an effect, versus some random directory that didn't have those features? I don't know. I'm out of my depth there, I just know it worked! This was the case on the 2 different web hosts I used for our various sites we converted from WP to ProcessWire; there was nothing unusual about the hosting environment in each case. It's interesting that you ask though because I did have a Wordpress thing that would "bleed through" while I was working on the ProcessWire site in the staging subfolder. This was the Wordpress security plugin Wordfence. It refused to let me put in any iframes (I have a few iframe ads) in my ProcessWire body field. If I tried to save a page like that, I'd get a Wordfence logo with a 403 forbidden. It likewise refused to let me embed any videos etc. So I made a list of those things as they came up (it was literally just a few occurrences) and added those in at the end, after uninstalling Wordpress and moving the staging subfolder to the document root. I had only managed to find one of them beforehand (Schedule Pages) and had taken a look but it said it was compatible to version 2.x and since I'm using the latest version of PW (3. something) I figured it might not be compatible, and I didn't want to try it in case there would be some problems with non-compatible fields or something like that. I wasn't worried if it simply didn't work, but I was concerned in case a 2.7 module would have some unintended consequences to a 3.x site. I had another look at the modules and searched the forums, but couldn't seem to find the other module. I'm guessing the various search terms I tried didn't quite catch it. UPDATE November 19, 2020 I recently tested the Schedule Pages module on another of my sites and am pleased to report that it works perfectly on a 3.x site! Thank you for this solution, it's perfect.

Here I'm introducing FlipFall Magazine, our multi-topic blog. It used to run on Wordpress but we recently switched it to ProcessWire. This was done the usual way we do it when converting our sites: install ProcessWire in a subfolder of the original Wordpress site under a hard-to-guess name, set up the new site there, then move content over manually, inspecting and updating each article as needed. After the ProcessWire site was ready, when we un-installed the Wordpress one and moved the ProcessWire site up one level to the document root, and... done. We used the W3CSS framework because it handles the responsive breakpoints so well (no extra work for us ?), and it tends to default to a clean modern look. We wanted full control over the back end of the site and do customized things without having to hire a developer. As FlipFall has grown, the ability to have in-house back-end control has become even more important. Case example: Ad partners - we now can quite easily, if we wish, place different ads on different topics on this blog at a moment's notice - no need to hire a developer. Changes like this can be implemented in-house right away. The fact that we can easily incorporate this sort of thing is really nice when we're talking with potential ad partners. Helpful features of ProcessWire during this experience: The ability to export and import fields in PW was key here. We had a few other article-style sites I had done in PW recently, so having the same types of templates was very helpful. We were able to export fields and templates from our existing sites and import into FlipFall as a starting base point. No need to re-invent the wheel here! Another helpful ability of PW was when we were dealing with the categories. We built the site without category templates (but with the category page field), then added the templates in later as needed - no disruption. In other words, a template-less page field worked perfectly for the categories until we needed the template, then we just created the template. Not every feature of the site needs to be thought out in absolute full beforehand, some can be added in later as needed. Very extensible and convenient. Internal links within blog posts worked well using the page select option in the link button on the editor. When moving out of staging folder and into document root, the links auto-updated, which was nice. Creating new articles is a breeze, because under PW our fields are now customized for our needs: we created all of the fields we need and none of the ones we don't. Again, this is unlike most blogging CMS's, where they try to guess what you want (and usually get it wrong). Even for people who are solely doing blogs/article sites, I feel that ProcessWire is a much better option than most blog-specific platforms, because of PW's flexibility. The only thing I miss about Wordpress is the ability to auto-schedule post publication, which for the serious blogger is important. For example, there were some occasions on some of our other blogs where we needed to schedule posts to auto-publish at 3:01am Eastern Time to allow a time-sensitive post to come out as early in time of day as possible on publication date (3:01 am US Eastern time ensures it's that same day 12:01 am on Pacific time). We were delighted to see that ProcessWire is much, much lighter on resources of the hosting environment than the same site on Wordpress - we could see this empirically on our web hosting stats before and after the switch.

+1 for Agree that multi-sort would be even better, but if not, then a simple page tree sort order flag ascending/descending preference setting would be so very helpful. For anyone who is making anything bigger than a simple few-pages site, this is so important. I have 2 sites that run ProcessWire which have 60+ pages each, and typically I'm much more likely to edit the most recently-written pages, not the oldest pages. Similar to Mikie, I don't want to install AOS just for this one purpose, nor do I want to install a module just for this. I like the UIKit admin theme, and I'd prefer it if the core could handle the sort order. As you can see in the case of one of my sites above, I have to click on "2" every time I want to edit any of the most recent pages. It's not a massive problem, but it can be a lot more frustrating than you may think for anyone who is regularly updating existing content. As a blog owner, this happens fairly often for me, and this is not my only blog. Also, 68 pages is not a large number of pages by any means, so sort order will affect anyone who is running anything more than just a small number of pages. I actually found this topic while searching the forum for a way to change the sort order of pages in the admin tree, but it looks like it's not possible, so I thought I would voice my support for this as a wishlist item. I love ProcessWire; the lack of sort order options is a miniscule price to pay for all the benefits that come with ProcessWire, so even without a sort order option I still enjoy ProcessWire. ADDED: I realized after writing this that (at least on UIKit theme) that in the admin panel I can select Pages>Recent instead of Pages>Tree, and I can get to the most recent pages that way. So, this is a decent workaround for my purposes thanks but I can see that other people might still prefer to have a pre-specified sort order for the tree, depending on their purposes.

Wow! This is perfect! ? Thanks for the different options of solutions you offered @dragan. I will go with this one you suggested: I am about to switch over one of my other sites. Am thrilled that with altering 1 line in the .config file I will save some clicking, and to be honest it's not just the clicking; I forgot to do it on one template, and then it took me awhile to figure out what was the problem when the rendered page looked weird. So this will save me quite a bit of time. Thanks again!

I know that we can disable the append of _main.php by clicking the box in the template file. However, is there a way to disable it by default, so that new templates created do not append _main.php? For those of us that never use _main.php, it's something that needs to be clicked every time a new template is created. Not a big deal, but is there a way to set it up in the settings to default to NOT appending? I tried different searches on the forum and haven't come up with anything yet. I understand more the default automatic prepend of _init.php because most people have variables to populate there before the rest of the page loads. Anyway, if there is no solution to my question, it's a minor thing, but thought I'd ask as I'm in the process of moving several of my sites to ProcessWire and this is a question that I think of often.

The final verdict is in! Thanks to everyone, I have moved the site to the new domain (actually it's duplicated but that's OK since I can erase the old one). When I started to act on the recommendations, I sort of accidentally discovered a 4th option (explained below) which worked. But I wish I'd done it the way suggested by @Robin S, @Autofahrn and @jens.martsch (updating $config->httpHosts in site/config.php). I'm sure that would have been even faster. So anyone else who comes across this thread looking to do the same sort of thing (moving site to new domain on same host), you might like to try that solution of $config->httpHosts in site/config . What I wound up doing However, I had not yet read those 2 latest responses at the time, so I was thinking about all the different methods and was looking to try the Duplicator module. Desiring to be a responsible site owner, I went to create a Softaculous backup of my site before trying the Duplicator module. This way I can restore my original site in 1 click if I do anything wrong. To my happy surprise, in the backup menu in Softaculous, one of the other options besides back up was "Clone site". Well, being curious, I thought "Let's try that, and if it doesn't work out, I can use one of the other methods people suggested". So, I tried Clone Site, and it worked perfectly! I just had to do point and click and tell it which of my domains to put the cloned copy of the site in, and boom, there it is at the new domain! After doing that, I then read the newest responses to my thread and realized that it would have been even faster to use the solution of Robin S, Autofarn and jens.martsch, but anyhow, the Softaculous method works too in case anyone has it available to them and was wondering about it. And after the site is in the new domain... A big thank-you to pwired for the advice given This turned out to be really helpful - I tried the search function in phpMyAdmin and found a few mentions of my old domain name still in there. It was clear from the results which pages I needed to edit in the processwire editor. So it may be a useful step for others too who are looking to do a similar type of domain move. Thank you again to everyone who responded in this thread. All of the suggestions were very useful. I really appreciate the sense of community here.

Wow! I'm blown away by receiving so much help here, and it's very much appreciated and needed! Thank you. I will be reading all the answers again carefully, but I thought I'd also post here answers to 2 questions that came up. Great point. This is a small site, more than a landing page but less than my other sites. It's maybe 15 - 20 pages on the front-facing side (that is, excluding admin pages etc etc). I plan to add more to it later, but for now it's fairly small. It's a simple site in terms of not needing other software packages etc - it's just straight processwire. Actually no, I'd be on the same server. Sorry, I should have mentioned that, I didn't realize that would make a difference. This is my first time migrating ANY site to a new domain. I do have several other sites running on that same host though, in case that affects anything.

In this case, I have a live Processwire site which I'd like to migrate to another domain name. I have come up with 3 possible approaches, and would like to please know which you think is best suited to my situation. Here are 3 factors to take into account: I have phpMyAdmin on both the old and the new domains, in case this helps. On the new domain I want to use Softaculous to do the initial Processwire install. This is for reasons other than ease of install (although it certainly makes for a fast install). I am not at all confident with SQL and would rather avoid it if at all possible. Option 1: Manual. Export field contents (e.g. title, body, etc) from current domain database into CSV format using phpMyAdmin. Install PW in new domain with Softaculous. Then in new domain, copy over the template files, and from PW admin screen of old domain export the fields and templates, save these details for import in the new domain. Copy over image files into assets folder of new domain. Create new pages manually and fill in field contents in new domain in admin office by copy-and-pasting from my CSV files. ? This is likely to work really well, but seems time-consuming. Anything that can give the same result but uses less time would be a big improvement. Option 2: Duplicator Use the Duplicator module ( https://modules.processwire.com/modules/duplicator/) - but I'm not sure if it's designed for use when moving to a different domain name (as opposed to just migrating same domain to a different host). Option 3: Site Profile Exporter Use Site Profile Exporter ( https://modules.processwire.com/modules/process-export-profile/) - but it's designed for use as a version of the site that you can share with others with no confidential data, while I need a regular full site. Hmmm.... Does anyone have any ideas which of the above options is best? Or is there a better approach that I have not considered?

Oh thank you! ? Can't believe I missed it.... I actually looked at the pages table but silly me was looking for "URL" as column label so I didn't even think to look at "Name". Oops. Yes, it's there, thank you so much! I exported the pages table as CSV and all is good now! Marking as solved. Thanks! ?

Sorry for this noob question, but I'm having trouble finding where the page URL's are stored in the database. Would anyone please be willing to point me in the right direction? Using phpMyAdmin, I've managed to find my other fields, like "body" "title" etc etc. However, I'm struggling to find the page URL's. I also tried searching the forum for this info, but I could not seem to find anything that matched. Ultimately when I find the URLs I'm going to export them as a CSV. I've already exported body, title, etc with no problems at all. But the page URL for some reason I can't seem to find. In the meantime, I've gotten some of the URLs from my sitemap.xml, but in that situation it's not indexed by page ID. Its a decent workaround for now and I'm happy to match URLs to page ID's manually, but for the future in case I didn't happen to have a sitemap.xml on my website, how should I find my page URL's using phpMyAdmin? ⚠️ To clarify, when I mean the URL, not necessarily the full https://.... I just mean the relative URL I defined in the place where I created that new page in the admin screen. I don't care about parents, children, domain name etc, just the url of that particular page (e.g. how-to-inflate-a-basketball ).

Here is GoodKidsClothes.com, a blog about kids clothes - news, style tips, sale alerts, and more. GoodKidsClothes.com originally ran on Wordpress, and I moved it to Processwire recently, the new Processwire version is shown above. There was a fair amount to change over, since it had 4 years on Wordpress before switching! I kept the colors, background, etc in line with what it had been before - a soft, friendly look. I wasn't seeking for it to be identical to its previous appearance, just similar but updated/better/more fun. The html I did from scratch, although I used the W3CSS framework. I love W3CSS because they handle all the responsive breakpoints, and the default styling is a clean flat modern look with plenty of great pre-sets. The reason I moved this site over to ProcessWire was not looks but actually functionality: the new Wordpress editor (Gutenburg) had just come out - one of its quirks is that it couldn't keep up with my typing, so I had to literally slow down my typing, which really defeats the purpose of WP as a blogging CMS. (Processwire's editor keeps up with me just fine). Also it was anyway time for me to manually go through and update old articles, put in new affiliate links etc, so I decided to do everything all at once and switch over to ProcessWire. In case anyone is wondering, the switch-over was manual since I was going to examine every article I'd written to either a) update it, b) move it to another of my sites, or c) trash it. This was not time-efficent but this way I wound up with being certain everything was up to date content-wise, plus no unwanted bloat (like extra WP fields) could make its way into my Processwire database. I simply installed Processwire via 1-click Softaculous install in a subdirectory of the original Wordpress site, with the original site still running. Then after I had the Processwire version fully finished (this took several weeks), I simply uninstalled the Wordpress version and moved the Processwire site into the document root. This way I had less than 1 minute downtime. UX/UI The first menu link is an all-abilities-inclusive version of "skip to content". The actual text displayed depends on which page template is being used ( this text is assigned in _init). For example, the Article template will display "Scroll to article", while Search Results template will display "Scroll to results". Link styling in the body of article content is designed for both the desktop and mobile user, with simultaneous underlining and highlighting showing the entire link region to aim for when tapping on mobile. On the home page and some other templates as needed, skip links are available within the page. They offer the option to skip past a series of links such as social sharing links, pager navigation, etc for a) the screen reader user and b) the fully-sighted keyboard-only user (no mouse). These links only become visible to the eye when focus comes upon them via tabbing. Tab through the home page to see it in action - this is the template where the most skip links have been needed. Cookie manager - originally I used a slider for turning Google Analytics tracking on/off but changed to checkbox because I could not work out a way to manipulate slider without mouse. Newsletter - field, and feed One feature of this site is its newsletter, and you'll see here how Processwire shines. The setup was (and still is) that on days when a new blog post relevant to children's clothes is published, subscribers get a brief email notifying them of the new article and linking to it. This is all handled by MailChimp, which I highly recommend. Under the old Wordpress system, I had to use categories to classify which of the posts wound up going into the newsletter (kids clothes) and which posts didn't (other topics like parenting etc). There was always the chance that under default WP behavior, things would be classified incorrectly if I forgot to specify categories. Under Processwire, I've set up the article template to have a field called "Newsletter" which is a simple drop-down choice of "For newsletter" or "omit from Newsletter". There is no default value, and it's a required field, ensuring that I do remember to specify it one way or another. It's such a relief to do it this way! My newsletter feed was easy to customize under Processwire: I created a feed template that selected a) all the pages using the article template that also had b) the "For newsletter" field selected, and those are listed at /newsletter in feed format. Please note that this feed may be empty right now - I omitted my existing articles from newsletter feed as subscribers have already seen them, and haven't had time to write new articles yet. To clarify, I'm expecting the newsletter feed at /newsletter to only ever be read by MailChimp, although it's certainly possible to be used by feed readers or read by humans. XML sitemap Under Processwire, I was able to generate a list of articles in XML format at /sitemap.xml that I can then submit to Google as the XML sitemap for this site. Best of all, unlike web-based crawler-type sitemap generators which generate a static sitemap that you then upload to the document root, my Processwire /sitemap.xml auto-generates each time the page is loaded, so it's always auto-updated - any changes in back office like article deletion, unpublishing, adding new articles etc are reflected automatically in /sitemap.xml. Some advantages of Processwire features when templating 1. _init.php file - my theme was designed for subsequent use in my other sites, so selected pages for use in nav menu (About, Privacy Policy) are automagically "found" in _init.php as follows: $pp = $pages->findOne("template=BN-infopage, sort=created, title*=Privacy"); $ab = $pages->findOne("template=BN-infopage, sort=created, title*=About"); 2. Made use of Processwire's built-in retina-friendly image resizing class, class="hidpi" to ensure social sharing icon links render at a decent resolution on mobile screens. Other info To check my html and to help identify problems that are not visible to the eye, I found it incredibly helpful to use the "audit" feature available on Chromium and other Chrome-based browsers. (F12->Audit-> select options you want). The order of the blogroll looks a little odd at first glance but it's ordered based purely on publication date. However, I updated some articles and they display the last updated date, which makes the blogroll look like it's not in date order even though it's in publication date order. Also some dates (the older article dates) reflect a user-specified date field, to show the article was valid at the time it was written (e.g. time-sensitive info such as reviews, sale alerts, etc). I'd be happy to explain further if anyone's interested. Moving forward as I write more articles, there should not be an issue, since I usually update only on or very soon after the publication date, so we should not expect to see wildly different dates on sequential articles from here on in.

I realize I never updated about this, sorry. It was all OK in the end - I reached out to Ryan, and it just looked like something had slipped through the cracks - my submission was made around the time that they changed they layout of the PW site directory. It got added in fine after I resubmitted. Thanks all for the input!

Thank you @szabesz - the thread you linked to was perfect, I don't know how I missed it in my search of the Processwire forums for the word "search" ? . Oops. Yes, my situation is a simple case of the one you linked to - just what I needed. Thank you @Robin S for the response here and in that thread - the info was very valuable. I've tried it out on my site and it's working perfectly!! ? Thank you both.? Now I'm just trying to figure out how to use the Limit selector on the resultant array (for pagination). But thankfully the main thing is that now it's giving the results I want in the correct order.

I've been trying to figure this out... It seems like I'm probably missing something really simple, but I'm still puzzled as to how to move forward with this. I'd appreciate any help or suggestions anyone can give. Aim: I'm trying to modify the default search template so that my search results come out sorted firstly with those which contain the search term in the title and secondly with those that contain it in the body. The basic code where I made sure everything was working first was: $selector = "title|body~=$q, template=BN-article|BN-infopage, sort=-published, limit=15"; // Find pages that match the selector $matches = $pages->find($selector); // did we find any matches? if($matches->count) { // yes we did $entries = $matches; include("./INC-main-blogroll-panels.html"); } It gave me the search results sorted by publication date, as I expected. Next I modified the first portion of the code by using the following to generate the matches as follows: $matchest = $pages->find("title~=$q, template=BN-article|BN-infopage"); $matchesb = $pages->find("body~=$q, template=BN-article|BN-infopage"); $entries = $matchest->and($matchesb); However, the problem is that $entries in my resultant displayed list did NOT start with those matches that were in the title first from $matchest. It seemed like $matchest->and($matchesb) sorted the resultant list its own way. This is even without the added complication of trying to use unique() afterward to remove duplicates - which appears to have its own default sort. Would anyone please point me in the right direction for what what I'm seeking to do? Thank you so much!

In case anyone is researching this topic, I can attest that this works beautifully on a live site! It was such a smooth and painless process! ?? I used Diogo's advice to go from Wordpress to Processwire on a site that I wanted to switch over. I had less than a minute or two downtime. Firstly, over a week or two, I built the Processwire version of the site in a subfolder (used a hard-to-guess-name) with the Wordpress version still running live in the root. Then when I was happy with the look of the Processwire version, I deleted the Wordpress installation via 1 click in Softaculous, which gets rid of the Wordpress database and the files, and leaves behind your own folders, like my staging subfolder containing the Processwire site. Then I just moved the contents of that staging subfolder up one level, into the document root. It renders just like it should. Done, and done. Thanks, diogo.

Thanks so much @kongondoand @adrian for responding. So far, I'm in two minds between a) simply assuming my site didn't meet some criteria, or b) wondering if it's worth re-submitting the form in case it somehow slipped through the cracks during a busy holiday season and some big changes to the way the PW site directory is displayed, or in case I did something wrong in it. When I submitted the original form back in November 2018, it gave me some code to add to my site pages, and I did it, so at least that part went OK. For now, I'll just leave it alone. Maybe I'm just not doing anything unusual enough or different enough with the building of my site (to be included in the directory I mean) ? and I would certainly understand if that is the case. Thanks again everyone, and I very much appreciated the time taken for responses.

Update Jan 2019: I'm a little puzzled as to why I don't see my site submission in the Processwire site directory yet. Maybe my site didn't satisfy some criteria?? Or does it take a long time between submitting the site to the PW site directory and it being added? I submitted my site to the directory back in November of 2018. If anyone can make a guess as to which of these issues is likely, please feel free to comment here. I'm a little puzzled.

Here I'm writing up about my first ProcessWire site, Reached.space, a blog and directory about shops which offer international shipping. I'm from The GrayFly Group, which is the registered trade name for GrayFly Stationery, LLC, a limited liability company registered in the state of Kentucky, USA. You might ask, why is a stationery company creating websites?! Well, in a way both activities are very similar: both activities have the goal of getting written messages across in a pleasing manner to the reader. With that out of the way, let's move on and explain what went on behind the scenes of the Reached.space site: Template I used a free CSS-based template from W3CSS at https://www.w3schools.com/w3css/w3css_templates.asp , using mainly the "Architect" template as the basis and modifying it as needed. Pagination The pagination feature of ProcessWire was very helpful here; I kept the home page to just two blogroll articles so that the reader was not overwhelmed, but upon pressing "more articles" the remainder of the blogroll is paginated with 4 articles to a page. Screen reader I made adjustments to my usage of the template to make it screen-reader-friendly. I used the Google Chrome extension to test out how the site would be handled with a screen reader. Security Security is always important, so I was thrilled to find a great all-in-one-place security guide in the ProcessWire docs at https://processwire.com/docs/security/ - I simply went through the guide and did what it said, using it as a checklist. Modules As far as I'm aware, the only additional modules I used (that were not already activated by default in standard PW install) were the Upgrade and Upgrade Checker modules. The main reason for this was security considerations, but it was also an added convenience and peace of mind to have it check for updates every time I logged in. However, I did use additional software that was not modules, as described below. Other software - Simple HTML DOM Here I was very fortunate to receive help from the ProcessWire community on the forum. Due to the site's monetization model being affiliate marketing, I wished to make all my external links nofollow and target _blank by default. User @Robin S was instrumental in showing me how to do this using Simple HTML DOM in the forum post https://processwire.com/talk/topic/17295-solved-how-to-make-external-links-nofollow-and-target-_blank-by-default-if-using-source-code-toggle-in-editor/ Other software - Google Analytics cookie manager My site requirements for GDPR were specific enough that I felt I would rather develop my own code to handle Google Analytics tracking, which I'll describe here. I wanted to be certain GA tracking was disabled by default requiring opt-in, instead of opt-out. I also included in the Cookie Manager some written info about third party cookies (these are placed when clicking on affiliate links) and how the user can avoid such tracking (turn off third party cookies in their browser settings). I also disabled front-end PW cookies as described here: https://processwire.com/talk/topic/15270-session-storage-and-lifetime/ Google Analytics cookie settings The Google Analytics cookie setting code was done using JavaScript. I used a session storage variable to indicate whether the user had a) accepted GA tracking cookies b) declined them or c) had not made a choice yet. I also had to make some changes also to the <head> code to ensure Google Analytics cookies were not set unless the user had accepted them. Efficiency - optimizing 404s I used the guide at https://processwire.com/blog/posts/optimizing-404s-in-processwire/ to sinkhole bot-driven 404 requests to a static 404 file. Back office pic Below is an image of how ProcessWire allows helpful field descriptions and displays them when used in templates, so that when I come to actually use or enter content in fields I created months ago, I know what the ramifications are. Very helpful. Also, when using the back office I found the Reno admin theme to be very pleasing, efficient, and easy to use.

Oooh awesome!! I can see how that would work but I would never have thought of it myself. Thanks @SamC! I really appreciate you trying that out. I'm leaning toward using markup regions now. One question, if anyone is willing to comment: using "markup regions" vs using "includes" - which of those two would you expect to be faster to render? And are there any conditions / caveats which favor one better than the other as far as speed alone is concerned? I know it said that markup regions can take a bit longer if you're outputting a lot of markup, but how do I know if I have a lot of markup? Also, wouldn't "includes" be considered an extra step just like "markup regions", so how do we know which one of these two would be faster for PW to render? I know there's most likely no hard-and-fast rule here, but I'm seeking some general thoughts about which conditions might favor one vs the other speed-wise.

@bernhard - Thank you for your awesome example! Yes, Sam had posted a link to the 3.0.49 post, but it was good to also see the updated 3.0.62 version of markup regions. The thing that made a huge difference to me was your code example. Your sample code here was MUCH easier for me to understand as a newcomer than the examples given in both of the official markup regions posts. If there are any other newcomers who are thinking of using markup regions, I strongly recommend bernhard's earlier reply above. It allowed me to see more easily how this would indeed help solve the general problem of having common bits of code. The advantage over the "includes" method is that the main layout code is in one place. In other words, I could therefore edit header and footer for all pages from the same file ( _main.php in your example), and I can see layout at a glance. High readability and ease of editing. I see I could add to _main.php all possible region ID's used in all templates; only the ones used by the specific template in use will get populated. So, it's pretty tidy, and you can get a feel straight away for what sorts of things all of your templates are likely to be doing, just by looking at _main.php. The main disadvantage I see is that I'm not sure what I would do if I ever created a page template that (for example) I did not want to include a footer on. Sure, that's unlikely to happen, but I'm not sure how I'd handle that using markup regions if it occurred. I expect there must be a way to do that, it's just not obvious to me. @SamC thanks for updating and also for mentioning the methods you are using. It is really great for me to have all of this info here from everyone all in one place.

Thanks for all of the additional info, @kongondo. And the delegate approach sounds interesting. It could be a good way to do it when there are some similar-ish templates, which is the case for 2 of my current 6 templates. So it could be a strategy to incorporate into those. However I'm not sure that I would want to do it for everything I'm using, because (correct me if I'm wrong), in that case I'd wind up using 1 template file with a bunch of conditional statements referring to 6 different templates. This, while elegant coding-wise, would surely have a little drawback in readability, at least to me. I might have misunderstood as I am still a newbie, sorry. I'm still very much trying to get to grips with everything and get my head around everything. In any case, I might incorporate this delegate approach for the more similar of my templates where there wouldn't be too many conditional statements. I'm glad that everyone has given me so many different templating strategies to choose from here. @szabesz - thanks, so glad for the warning and for the link to the info about relative paths! Actually I had wondered about that, which was one of the reasons I'd kept my inc files in the same directory as my template files. My own naming convention for my inc files is INC_filenamehere.php , since my editor handles the .php files well, but won't recognize a .inc the same way, and I don't like editing plain text. I like the markup and things to be in different colors like they are on .php files. (Yes I know I can probably change the editor settings to recognize .inc files but I'd prefer to instead go for a filename convention that works for me personally). Plus having inc files start with INC_ means they are all grouped together alphabetically in my template directory anyway. I will update my paths using $config, just as kongondo recommended, so that this way I can ensure that the path is specified explicitly to sidestep the whole problem altogether. Thanks, I read the other 2 articles you linked to also, very helpful info when thinking about templating strategies. Thanks, it's helpful to get ideas of how people are doing it for their own sites. All of this discussion has forced me to think about what's most important to me when templating. It's probably readability and layout. In other words, I need to be able to come back to my templates 6 months from now, and if there's a change I want to make on the page (whether it's displaying a new field or changing some of the styling), I want to be able to do it as quickly as possible without needing to track stuff down much. Parts of my templates can be busy, especially when I have a bunch of nested divs etc with different classes, but it seems to be the main way that makes sense to me while still functioning responsively. Anyway this has given me lots to think about and it's helped highlight to me that there are lots of different possible templating approaches due to the flexibility of ProcessWire. It's not even restricted to only the methods mentioned in the tutorial I had first read. I really appreciate all the help I've received here from everyone.