Violet

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.

Thanks to both of you for the updates. @kongondo , the $config is a good idea,I will replace my paths on the "include" with that. Valuable info. You also mentioned I should consider delayed output. When reading up about it, I came to the conclusion that I'd have to sit around and do a lot of concatenating of strings every time I create a new template file. I'm new to ProcessWire, so maybe I've gotten it wrong, but I just don't like the general idea that I have to pre-define every output I want to make as a string first, instead of just using variables here there and everywhere on the fly as I update/change my templates (the latter is what I love about ProcessWire). I will think about all this. In the meantime, will change my paths to $config ones. @SamC , thank you SO MUCH for going to all the trouble to actually test out the namespace on the "include" files. While my setup was working fine without the namespace, I'm DEFINITELY heeding your warning that depending what you have going on in your files, omitting the namespace may lead to errors. As you say, it can't hurt to put it in. I'll change my files around to add those in. Thanks so much! What you said above about the limitations of the "includes" method was very valuable too. Hmm. Thanks also for the link to the new template strategy; this was extremely helpful as it was not mentioned in the tutorial that I had read in my first post (why??). I'm not certain if the new template strategy is ultimately what I'm looking for; I'll have to think about that carefully. The reason is my template is heavily CSS-based, and I'm not a big fan of using classes like pw-append and pw-prepend. I can see how on the one hand the new system would allow flexibility when using different templates on a site; on the other I don't like the notion of using classes that aren't defined in my stylesheet. I realize ProcessWire handles those tags itself; I just don't like it from an ideological point of view more so than a practical point of view. Plus, I don't want the pw classes to be at war with either my classes or my screen reader strategy. Perhaps it wouldn't clash, but it still doesn't seem like the most readable templating method to me. I read your second edit, and I was beyond thrilled! I think this is what I might go with! It sounds like exactly what I need. I will try it out. This is hugely valuable info thanks.

Hi @SamC thanks so much for your very helpful and thorough reply. I went through your code for your two different examples. Thanks, I think I see what you're saying here. Upon reflection, I think I have something more like your second method in mind, mainly because I have a fair amount of fields to output from the post list and a fair amount of styling going on in there. Therefore if I decide I want to later add in and display an extra field for each item in the list of 3 in the <aside> section (this is in fact exactly what happened yesterday), I just want to edit ONE file (the one called by "include") and not every single one of my template files. Also, sorry if I inadvertently made my wording confusing in the original post. Oops . When I said "all templates will display an identically-formatted list of 3", I did not mean that all 3 items will be displayed identically to EACH OTHER. This is why I did not loop. I just meant that the layout of the 3 will not change between templates. So, for example the first post title might be displayed with full-width photo, publication date, and with an excerpt. Posts 2 and 3 might be displayed below that but next to each other (one on left other on right), with title and just thumbnail pic, no excerpt. Still tinkering with my design layout, but ultimately I want the final layout and final fields of the <aside> section to be the same on all my different templates (e.g. post 1 details always shown full-width; posts 2 and 3 always displayed below next to each other). So that's why I was wanting to use include. My displaylist.php basically looks a lot like your example, but with lots of styling and with separate display of each of the 3 post fields. IMPORTANT QUESTION: Your example showed I was supposed to begin the file displaylist.php with: <?php namespace ProcessWire; ?> The file calling it i.e. the code from my template file I gave at the start (currently called _temptest.php ) ALSO starts with that: <?php namespace ProcessWire; ?> <!DOCTYPE html> <html lang="en"> <head> .... So to clarify, do I still need to specify "namespace ProcessWire" in file displaylist.php even though file _temptest.php (which calls displaylist.php) starts with the same thing? And thanks again for all the help you've given me above. I really appreciate it.

I originally created my template files thinking I'd only ever need 3 and not worrying about if I repeated bunches of common code there (yes, bad practice, I know). I figured I'd just manually/copy-paste to change any common code in all 3 as needed. So of course, fast-forward awhile, and I'm now up to 6 template files with possibly a few more to come, and decided it was high time I made the switch to keep the common parts in their own unique files for ease of editing. So I therefore went back and read Ryan Cramer's tutorial "How to Structure Your Template Files". OK. I tried out the "includes" command mentioned in the tutorial on a test template. The resultant web page physically functions as expected, but my question here is, "Is the practice I'm showing below OK in terms of variable usage?" If not, what approach should I be using? I've tested it out and the variables do populate as expected in the final result, but is it OK for me to do it like this or is there the chance that some of the variables won't be passed properly? Here is what I mean (only the relevant portions of code shown to illustrate): ... <aside> <h3>Three Random Posts</h3> <!-- get the list, then display it --> <?php $itempages = $pages->find("template=my-post"); $shortlist = $itempages->getRandom(3); $shortlist->shuffle(); $itempagezero = $shortlist->eq(0); $itempage1 = $shortlist->eq(1); $itempage2 = $shortlist->eq(2); ?> <?php include("./INC_displaylist.php"); ?> </aside> <?php include("./INC_footer.php"); ?> </body> </html> The possible issue here is that the INC_displaylist.php file outputs field data from $itempagezero, $itempage1, and $itempage2. Is that OK? I wanted to split the variable assignments and the output separately. This is because, based on the exact template I'm using, I will sometimes choose to populate $itempages via different selectors in the $pages->find command in different template files, although all templates will display an identically-formatted list of 3. By contrast, I wouldn't expect any variable issues with including the INC_footer.php file as shown above, since I'm not using any variables in the footer that aren't first referenced in that same footer. So am I doing it OK here or should I be populating these variables somewhere else to ensure they're recognized properly by INC_displaylist.php? If I need to do it somewhere else, where should I populate these?

Thanks @adrian, sounds like the Tracy debugger module is just what i need.

Thank you so much @Robin S for clearing up that mystery! I had not realized that != was not supported by default for path or URL. I appreciate this info. And yes you are 100% right, I had debug mode off; I probably should at least turned it on temporarily while trying to figure out my problem. I'd completely forgotten about it. I'm developing my site live instead of starting on a local server, so for security reasons I had turned off debug mode. That said, I should have turned it back on while I was trying to figure things out with my selectors. Will definitely remember to do that first when I next get stuck, as I can see from what you're saying that the debug exception messages will give me valuable clues about what I'm doing wrong. Thanks again, I really appreciate your help. Marking this thread as solved.

I'm having trouble with my selectors when using !=. I'm sure I'm making some newbie mistake, but I'm just not sure how to fix it. This code below functions as expected: $results = $pages->find("template=basic-post, limit=1, path=$post1path, sort=-userpubdate"); but this one (the one I actually need) doesn't work: $results = $pages->find("template=basic-post, limit=1, path!=$post1path, sort=-userpubdate"); It results in an internal server error. How should I have phrased it instead? My intent is to find all pages with the basic-post template but excluding that one specific post. In both cases, $post1path = $post1->url; echo $post1path; where $post1path echoes as expected with the path of post1. The variables therefore seem to be working, but I must be making some sort of fundamental newbie error in my page selection. I would appreciate any guidance that anyone can give. I didn't want to use slice() or other things after getting the page array, as I want to be able to use pagination. UPDATE: I *think* I have gotten around the issue by using ID's instead, where $post1id = $post1->id. $results = $pages->find("template=basic-post, limit=1, id!=$post1id, sort=-userpubdate"); And it seems to paginate correctly as far as I can see - I still have to do more testing with a bigger array to be certain, but it's working on my small test array for now. I'm still curious why path!=$post1path did not work, if anyone would like to comment on that for me. But at least there is a solution that, so far at least, seems to work.

I was a little hesitant to reply at first because I am a newbie to Processwire, also coming from a Wordpress background. However, I thought on the other hand, perhaps my point of view (similar to your background @svsmailus) is exactly one of the points of view you might want to hear from, in addition to those from experienced users. I would classify myself as mostly a non-coder, however from customizing minor stuff on WordPress over the years, I've managed just fine starting out in Processwire, so if that's you then you would be fine too. Learning-wise, I picked up what I needed to know as I went. I am still learning as I go. It all comes down to what you want to do with your site. I don't have the know-how to create a fancy site with lots of user input or advanced features like that, but on the other hand I needed something beyond a standard blog, with a totally custom layout and customized data fields; all of which I couldn't achieve on my own in WordPress. People have been helpful on the ProcessWire forum and usually I can find what I need by searching, and upon asking a question I got some really great answers, one of them with code shown that I could (and did) use and which proved super-helpful for my custom needs. All that being said, it is a bit more of a learning curve in Processwire and yes you do need some basic PHP (although so far I haven't used much more than echo statements and if...then statements), and a few chunks of HTML and CSS. I've never used the blog module for PW so I can't comment about that. Instead I created my own theme files (I actually based them off the free responsive W3 CSS templates) and made a page template of basic-post which consists of a navbar, a header, the page content, and footer, so it's pretty simple. That could be a great place to start. To begin with I added in some custom fields like featured image, and a check box for if I wanted to display the image on the basic-post template (this allows me to toggle on/off the display of featured image at the top of the article, for example I like to toggle that off if the body of my article is already image-rich). I was able to add to my layout as needed and put my extra customizations and extra display fields in. Overall, from the beginner's point of view, as a beginner myself to ProcessWire, I wholeheartedly agree with what @Peter Knight said. The way he suggested is how I happened to do it myself and I can already see how powerful and un-bloated ProcessWire is (compared to Wordpress). It's also actually fun! I also agreed with what @louisstephens and what @adrian said (and many others too; those two just stood out) in that as a beginner you don't actually NEED a whole lot of PHP at all besides echo, if-then, and foreach.

OK, I tried out the code from @Robin S and it works perfectly! It's an incredibly powerful and elegant solution, especially since it works on page save instead of front-end load. Besides trying out a standard link, I also tested it out with actual affiliate links and banners, which are a lot more complex-looking than a standard link, and it worked perfectly. For anyone in the same situation as me who wants to use Robin's solution, you should remember to first un-set the nofollow and _blank link attributes in ProcessPageEditLink (i.e. don't have those in the two boxes in the pic I showed in the original post up top). Then, just do what Robin said. It all just works! I'll mark this as solved. Thanks again Robin S!

Thanks everyone for these answers. @adrian I liked the idea of the module, but when I looked at a discussion thread of the module, it says it should only be used on PW 2.x and not 3.x. Indeed, the module itself is only listed as compatible up to 2.7. I'm not sure if that means I still could use it successfully in my site, or that I might break things if I try that. I'll think about that. Even if it works, I'm a little hesitant to use a module that isn't designed to be used with future PW releases. Thanks for the info and I'll definitely keep thinking about this. @Robin S Great, thanks for this code. I had never thought to use a separate HTML parser, and I love the idea that it does it when the page is saved. Very nice. Thanks for showing me how it should be done, as this is beyond what I would have been able to figure out on my own. Thank you so much.

I've set the ProcessPageEditLink module to ensure that external links are nofollow and target is _blank. Below is an image showing those settings. This works PERFECTLY for links that I add in via the editor, but the problem is that when I toggle editor to "source code" and add in links that way, it won't default to making the external links nofollow and target _blank. It only works when I put the link in via the link button in the editor. The reason this is a bit of an issue is that most affiliate links (which is exactly what you would want to apply this to) are usually given by the company as source code, so I am adding them in by toggling editor to "source code". In that situation, I just can't get the links to default to nofollow and target _blank. Some solutions I tried: I can add in those attributes manually to my source code, which works, but it's frustrating to do it on each and every link that I'm putting in. Another option that seems to work is clicking on the link inside the editor AFTER toggling out of the source code mode window, and opening up the new link in the editor and hitting "submit", which forces the editor to re-edit the link with the attributes added. But likewise, this is rather clunky and time-consuming, plus I have to remember to do it every time. However, being a newbie to ProcessWire maybe I have overlooked something. Have I been doing something wrong, or is there a workaround that someone could suggest? I'm hoping to figure this out early on, since I'll be using affiliate links in my new website. Thanks for any help that anyone can provide.