Leaderboard

Dear Ryan and All, The above quote is what brought me to PW, and what makes me stay. I've built three magazine style "CMS" sites with ProcessWire, and it was a joy. But I've also built an email-driven, web help ticket system, as well as an entrepreneurial, formula-based business application to vet new startup concepts. (Both apps are non-public, user-login-only apps.) Once I understood ProcessWire's methodology and API, I was free to focus on the design and implementation of the above custom business applications without worrying about ProcessWire getting in the way -- because it didn't. I wrote PHP template scripts with the API, using the page-based methodology, and it was a dream come true. I shudder at the idea of trying to replicate the above web database applications in WordPress or Drupal. Someone probably could, and they're welcome to it -- but it "ain't me." Also: I've probably missed a post that you've already written, but do you have a post that thoroughly explains the benefits, virtues and rationale behind using the "virtual table method" PW employs, by stitching one field per real table into field templates? I'm comfortable with it now, but for folks who are used to regular data tables, with a set of fields in them, PW's method is very new and very different. A prominently placed white paper on that would be very helpful, I believe. Kudos, Ryan! Peter

Here you go guys: https://processwire.com/talk/topic/2387-the-structure-of-fields-and-templates/?p=22762 (found via a link halfway down this article: http://www.flamingruby.com/blog/anatomy-of-fields-in-processwire/ ) I know ryan has explained this several times over the years but I agree that as one of the real "what the heck?" points that come up when you're first exploring ProcessWire some page dedicated to it on the site and linked to wherever fields are mentioned might not be a bad idea

Your select fields are most likely page fields. They hold reference to another page. Those numbers which you see are page ids. To output fields of the referenced pages you should do something like: <p> <?php echo $page->Battery_Manufacturer->title; ?></p> Here is a nice video tutorial about this type of fields. But you probably already know it if you're using it.

Hi mikeroosa and welcome to PW. Both of those are optional. The leading underscore is simply a convention so you know those files are not actual template files, but rather php includes (files that get included into other files). This is also common outside of PW. The omission of the closing tag has several benefits. A quick google will help to explain why: https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=php+omit+closing+tag

Stroke upon stroke... Another one online: http://aureliusinvest.com/en/ (english) and http://aureliusinvest.de (german) German Investment Company. Porting old website from MODX to PW (by hand mostly), added some more emotional imagery and a bit more what they actually do and how they work. Nothing special to say about the used modules, it is mainly content and images which has to be managed by PW.

.inc is sometimes (including in the "Essential PHP Security", unless my memory fails me) considered bad practice, mainly because it has to be separately handled by .htaccess rules. If .htaccess fails for whatever reason, your .inc files are suddenly world-readable. Though a lot has to go wrong before this can happen (and even then it's usually far from critical), so far I haven't heard any compelling reasons to use .inc instead of fail-safe alternatives, such as .php (or .inc.php, if that .inc is somehow really important).

That's true, but not inside PW

They are either included in template files with the php include statement or autoincluded in site config file. You can read this wonderful tutorial to get all the nuts and bolts quick. They also can be included in the admin in the FIles tab of the template edit page.

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.

FANTASTIC! I have tested your module. It works perfectly and like it a lot, simple and effective. Thank you for sharing!

Another alternative: https://github.com/adrianbj/ProtectedMode I haven't added it to the modules directory just yet. Official forum post: https://processwire.com/talk/topic/7723-protecteddevelopment-mode/ Modules directory: http://modules.processwire.com/modules/protected-mode/ The reason I built this, rather than using the Maintenance Mode module was: I didn't want the "Maintenance Mode" badge showing up on the site since it really is for development before a site has ever been live. I didn't want users redirected to the PW login page because I did want visitors to see the login page. I know the module has the option to redirect to a custom page, which you could use to make a front-end login form, but that seemed more complex than I needed (and I think other PW devs might also need). Because of the way this module replaces Page::render with the login form, visitors can be sent to any page on the site, and once they login that page will reload with its full content - no messing around finding the page again, and no need for sending page ids through the login process to redirect back. This module also lets you configure the message that is displayed along with the login form. I don't see this as a replacement for Maintenance mode at all. It has less options and is not really appropriate for scheduled maintenance time - it doesn't send a 503 - although Maintenance Mode doesn't do that either. If you try it, let me know how it works out for you.

The get() in InputfieldWrapper is assuming to get a field by name and is not using a selector like a find. /** * By default, calls to get() are finding a child Inputfield based on the name attribute * */ public function get($key) { if($inputfield = $this->getChildByName($key)) return $inputfield; if($this->fuel($key)) return $this->fuel($key); if($key == 'children') return $this->children; if(($value = parent::get($key)) !== null) return $value; return null; } You could also do $form->find("type=submit")->first->name;

This is the nature of how the ajax uploading works, as it triggers a page save (though saving only the field you upload to). One way we could solve it is to add a status field to the file/image fieldtypes, giving them a way to identify a file as unpublished. Not sure how simple it will be to implement, but this is one of the things I've had on my list for awhile. If it comes up more often, I'll definitely bump it higher up the priority list.

Joss actually emailed me a similar question and I'll duplicate my reply here since it seems relevant: Performance as it relates to database is really not an issue that one needs to consider much (or at all) when it comes to creating their fields. Most field data in ProcessWire is loaded on-demand. It loads data selectively and only when it needs it. This enables it to be highly memory efficient with large quantities of pages in memory at once. When you have a $page, behind the scenes, none of the page data is actually loaded until you access it. For instance, if you access $page->body, then it goes and retrieves it at that moment (if it hasn't already retrieved it before). MySQL is extremely fast with simple primary key, non-joined selects, and we take advantage of that. What I'm trying to get across is that quantity of fields does not translate to an increase in joins or other factors that would slow the system down. Where ProcessWire does join data automatically is at page load time is when you check the "autojoin" box on a Field's "advanced" tab. Some fields you know will always be needed with every $page instance, and that's what autojoin is for. Typically, I make my "title" field autojoin, as it is already by default. I've hidden that autojoin option under the Advanced tab simply because most people never need to consider it. The original intentions behind autojoin have become less applicable than I originally thought [with regards to performance], so it's not something that comes up that often. ProcessWire also uses joins when it performs queries for $pages->find("selector"), and related DB-querying selector functions. It joins all the tables for fields that you query. So if you perform a find for "date>2012-12-19, body*=holidays" then it's going to join the field_date and field_body tables when a value matches. Though it doesn't do this for the purpose of loading the data, only for matching the data. Technically this type of query could be potentially faster if all those fields were in one table. But that doesn't translate to results that matter for us, and doesn't affect the way that you should use ProcessWire. The benefits of our one-table-per-field architecture far outweigh any drawbacks. I put a lot of time into finding the right architecture and balance here when coding ProcessWire 2. Incidentally, ProcessWire 1 did use the one-table approach (all the field data was stored with the page rather than in separate tables) and it was far less efficient with memory, and about the same in terms of performance. It's better to re-use something like "body" (when possible) rather than create "article_maintext" or other template-coupled variations like that. The reasons for that are for your own benefit. It is less to keep track of, and tends to foster better consistency. It also results in more reusable code and broadens the potential of where the data can be used. Take the example of an on-site search engine, like you see in the upper right corner of processwire.com. If we know that the main text field(s) of most templates has some consistency in their field names (like title and body), then we can write code that doesn't need to know whether something is an article, a press release or a product. We can find all pages that match "holidays" in the text just by doing this: $pages->find("title|body*=holidays"); But if created a separate textarea field for every template, then any code that queries those fields needs to know a lot more about them: $pages->find("title|article_maintext|pr_maintext|product_maintext*=holidays"); While that still works, it doesn't scale nearly as well. This also translates to the code you use to output the results. If you want to show a snippet of the matching text with the search results, you are going to have a lot more fields to consider than just "body". Now if each of your templates genuinely needs very different settings for each of their main text fields, then of course it's fine to create them as you need them. But in the real world, I think you draw more benefit by planning for reusability when possible. The benefits are for you (the developer), as it doesn't matter much to ProcessWire. Reuse fields where it's obvious that the name of the field makes sense in the context of multiple templates. If template "employee" needs a date_of_birth field and template "press_release" needs a date_publish field then just create one field called date and use it on both templates. On the other hand, if you need multiple date fields on the same template (like date_unpublish) then more specific field names start to make sense. In that case, I would usually use my date field for publish date, and create a separate date_unpublish field for my unpublished date field. Though some may prefer to actually have separate date_publish and date_unpublish fields because they are obviously related by name. Ultimately, use what works best for you, but always keep an eye out for obvious reusability potential with fields. I think that most people naturally arrive at the right balance for their needs after some experimentation. What is a best practice for one need might not necessarily be for another. So these are mostly general purpose guidelines and people should find what makes the most sense in their context. For the majority of cases, I think avoiding tightly coupled template and field names is a better strategy. TL;DR: It doesn't matter to ProcessWire what you do. Aim to reuse fields when you can and when it makes sense, for your benefit.

Currency Conversion for ProcessWire This module is designed for performing currency conversions among ~165 world currencies. It uses OpenExchangeRates.org (or compatible) for data so that currency exchange rates are always up-to-date. It provides various API functions that you can use to convert from one currency to another. This is especially handy for generating rate tables in multiple currencies or giving users of your site the option to see prices in their currency. How to install How to use API documentation Modules directory page GitHub Page Download ZIP Live Example Requires ProcessWire 2.4.0 or newer. To use the quick-installer from your modules screen, paste in ServiceCurrencyConversion. Basic Example $cc = $modules->get('ServiceCurrencyConversion'); $dollars = 100; // amount of currency we want to convert $euros = $cc->convert('USD', 'EUR', $dollars); echo "<p>$dollars US Dollars equals $euros Euros</p>"; For a live example of a currency conversion tool built with this module see the included convert.php file and test it out here.

Yeah, I fixed my own issue. I just reloaded the .htaccess file with a good known copy. All is well.

@pwired $SillyGuy = "pwired"; echo $SillyGuy . " please insert code into the code box";

Has this something to do with pw 2.5.0 because the header.inc and footer.inc in that version are gone ? Although you can re-create them for your self at any time can´t you ? I also like those .inc files because with them I can let pw manage my markup in an easy way. Has one of your pages a different look, just include different .inc files with the same output between the html tags. Someone said that those .inc files are not safe because the code inside can be read by anyone over a direct internet url. Further I have not the faintest idea about what delayed ouput is let alone it´s advantage. https://processwire.com/docs/tutorials/how-to-structure-your-template-files/page4

Very usefull module, thanks. For me an easy way to inject custom jQuery wizardry into some pages, without touching the core modules.

Hey, that's mine!

I don't understand how delayed output is more scaleable, and I definitely think it is more confusing for your stated target audience. I actually find the opposite to be true for me in terms of scaleability (or at least flexibility), because delayed output forces me to use the same overall structure (the variable "bins") for all of my pages. It also forces you to write all of your markup in a php-first way (unless you know how to use output buffering) instead of an html-first approach, which I think is more appropriate for template files and easier for front-end developers to work with. When I do find myself repeating myself in the template files, I can just use php includes for any section of code that is used in more than one template. Don't get me wrong, I love php. I just think that it should be as "loosely coupled" from the markup as possible. When it's time to write html, I want to think more about html and less about php.

Thank you , i have to say that you guys rock !

Talking about it, this would be a good slogan: Free your website with Processwire - - - - - -

Pencil http://pencil.evolus.vn/ http://pencil.evolus.vn/Features.html

I haven't managed to test out this new module yet, so I am not sure, but I think it should do what you are looking for: https://processwire.com/talk/topic/6822-module-dynamic-roles-for-pw-246/

Damn it is embarrassing that I felt the need to Like that suggestion of Joss'. I used to be fine on a 15" laptop running 1920x1200. Seems like 40 really is the beginning of the end when it comes to small things and low light

Ryan, next time you're are messing with the module, fancy putting in a drop down for font size on Ace? For us old blokes, you know......

Okay, I now have it working ... er, sort of. It turned out that the tmp partition on the box was full, which was why it was not sending mail. This must have been affecting everyone on the box, of course - a minus point for Kualo there, who normally get good reviews. But then, at least they found the problem.... Currently using mail() direct on the script - not actually getting anything else working at the moment, but at least I have got the form working

And here's an excellent Hanna Code snippet by Diogo that lets you choose which images in a page to display https://processwire.com/talk/topic/1182-module-image-tags/?p=40015

I think it makes sense to keep the direct output, since more advanced developers will most probably start with a blank state anyway.

Processwire is mentioned here https://www.youtube.com/watch?v=rDQb_EMNRx8

http://www.tinyprocesshouse.com/posts/why-processhouse/

ProcessFish

Oh yes - Ryans post screams to be put on a subsite like processwire.com/philosophy.

Code before talk. With 2.5.0 released Friday, and 2.5.1 dev released today, there's been a lot of code.

I think it is terribly easy to clutter up a ProcessWire installation with a huge amount of information. One thing that is important to remember is that ProcessWire is not WordPress and is not aimed at the casual blogger with little knowledge hitting an install button on their CPanel. ProcessWire is a true CMS in that it is a system that manages content - whatever that content is. Because it is agnostic about the nature of the content, by nature it requires a certain amount of development input post installation - in other words, its strength is that it does not try and force you down a certain route. Consequently, it really is a development CMS, even though it is incredibly easy to learn even for non-developers. So, I agree with Diogo just above that all that is required is links to useful tutorials and for the actual installation to be as clean as possible. As an additional note, I would like to see a way of reverting the installation to a clean state. So, for instance, you can install with demo content, or maybe a third party tutorial profile, but once you have finished, you can press a destructive button to "install clean profile." This effectively removes all trace of the existing profile, wipes the database (keeping the admin user details) and gets you back to a blank install. This button would, of course, need to be available as part of the disposable profiles and not there by default! Would not want any accidents......

Gonna mention it again: We're working on snippets.pw

woop, you hide the best part on the last slide. To quote his PDF: I like ProcessWire the way it is. Clean and minimal. Please, don't tell me how to do things. Instead focus on tutorials, guidelines and articles that explain how to use the tool ProcessWire to build great sites. My first site with ProcessWire was quite easy and not a complex monster. I learned how to use different field types and how to structure content with each project and I'm still impressed, when I find a new way to solve a problem with ProcessWire. That wouldn't be possible, if I had everything finished. Then I would say "Oh thats great but not exactly what I needed". ProcessWire as a clean and minimal CMS/CMF to build a website is great. Ryan should try to improve the system itself and keep bloat away. (In my opinion, the new 2.5 with all it's profiles is even too much to start). There are other areas to improve, beside the system and most of them were mentioned before in this thread: Better onboarding process that guides the users A single place for all the little code snippets and fragments. Tutorials for beginners and experts. Maybe have a look the new Kirby docs More site profiles to start with, but not bundled by default (Download during the installation?)

I think the issue, why this doesn't exist in this form, is that, according to the pw core priciples, most people here don't want to glorify one way of solving things, but much rather tell you how to do it yourself. I can understand that this is not the best way to appeal to newbies and I also think there could be done more to ease the entry of working with pw. One would like to have a big teaser image on their blog, while others want a "x" layers deep categorization for their thoughts. If you want to add all possible scenarios you'll likely end up with bloat. Most other CMS's out there just tell you which content you have to use. A standard Wordpress installation can manage exactly four types of content: articles, pages (more or less the same as articles), comments and "media", while telling you how all those type should look like. It just gives you a blog. Only all those plugins try to make it something more.

I was reading all the posts in this topic with big interest. When I first read the title of this topic I was thinking "what exactly are you talking about? ProcessWire is the most userfriendly CMS I've ever seen". As I read further (the first post) I understood the big difference in what people in this forum think is a user. For me a user is a person that uses the backend of PW and because PW IS a CMS this means the user is able to manage contents. Nothing more, nothing less. If you are in that mindset PW delievers a great user experience, because everything the user sees is exactly what he/she needs. There are no useless fields and there are no complicated mechanisms to publish different types of content. This is a real additional value for the user as this kind of CMS is way easier to grasp. (in opposite to let's say 5 plugins/addons/modules which are all from different devs and therefore have all a different workflow) On the other hand, this means there has to be a real web designer/developer, beause the user will never be able to get new features by themselfs. This person is not in the user role, he/she is the webmaster/administrator. This makes PW perfect for professional use and personally I think this is the right direction.

I think this is the problem, the catering bit. PW is a one man company with a small group of talented and helpful contributors. The current situation is that there is just enough people to manage and support PW as it is. If it grew a complex layer on top of the existing system that would need to be monitored, continually updated and so on, then it would quickly become unmanageable. One of the reasons that there are so many CMS type system out there full of bugs (especially plugins) and have huge maintenance issues is because they grew beyond the ability of the original developers to control and maintain properly. In that way, growth does not add value, indeed it can undermine it. As several of us have said, the profile system allows for variants to be created that can be installed as part of the main installation. So, if some users want to create a profile that offers the same sort of plug and play features as WordPress or Joomla, then that is by far the better way to do it than to expect the core maintainers to do it and in the process risk the integrity and maintainability of the system as it stands now. Really, this is nothing to do with what CAN be added to ProcessWire in the way of additional functionality - we all know that anything is possible - really this is about WHO adds all that functionality and who has the time to maintain it properly: if even just a thousand people use that sort of system and want support, then that is a full time job on its own.

CMSs make hand coding by editors obsolete (as it was usual in the ancient times), thus allowing content to be published quickly and easy. That's what I understand from this sentence. I don't understand, that CMSs allow to build web applications (sites, apps) without coding skills. Even WP requires coding skills if you want to take it one step further (in fact, it requires much more coding skills than PW does ...) .

One other immediate solution is to use Ryan's Hanna Code. I adapted the module to Hanna code, and it seems to be working pretty well, although the tags are a bit different: {fieldname:2} and [[images f="fieldname" n=2]] It looks a bit more complicated at first, but it's not really. Here is a resumed explanation: defaults: [[images p="0" f="0" n="0"]] where p is the page number, f is the field name and n is the image position on that field. The above is equivalent to simply: [[images]] And it will get all the images from the first field of the "image" type on the same page of this Hanna Code field. Because: if $p="0"; // $p will hold the $page object if $f="0"; // $f will hold the first images field found on $p if $n="0"; // $n will echo all the images from $f From here you can have any combination: [[images n="4"]] // echoes the image on the forth position of the first image field of this page [[images p="1" f="myimages"]] // echoes all the images of the field "myimages" in the homepage That's it. Here is the string to import this Hanna Code: !HannaCode:images:eyJuYW1lIjoiaW1hZ2VzIiwidHlwZSI6IjIiLCJjb2RlIjoiXC8qaGNfYXR0clxucD1cIjBcIlxuZj1cIjBcIlxubj1cIjBcIlxuaGNfYXR0cipcL1xuJG15UGFnZSA9ICRwID8gJHBhZ2VzLT5nZXQoJHApIDogJHBhZ2U7XHJcbiRmaWVsZE5hbWUgPSAkbXlQYWdlLT5maWVsZHMtPmdldCgndHlwZT1GaWVsZHR5cGVJbWFnZScpO1xyXG4kbXlGaWVsZCA9ICRmID8gJG15UGFnZS0+JGYgOiAkbXlQYWdlLT4kZmllbGROYW1lO1xyXG5cclxuJGluZGV4ID0gJG4tMTtcclxuXHJcbmlmKCRteUZpZWxkIGluc3RhbmNlb2YgUGFnZWltYWdlcyl7XHJcbiAgICBpZigkbil7XHJcbiAgICAgICAgJGltYWdlID0gJG15RmllbGQtPmVxKCRpbmRleCk7XHJcbiAgICAgICAgJGltYWdlID0gXCI8aW1nIGNsYXNzPSdJbWFnZVRhZ3MnIHNyYz0nJGltYWdlLT51cmwnIGFsdD0nJGltYWdlLT5kZXNjcmlwdGlvbic+XCI7XHJcbiAgICB9IGVsc2Uge1xyXG4gICAgICAgICRpbWFnZSA9IFwiXCI7XHJcbiAgICAgICAgZm9yZWFjaCgkbXlGaWVsZCBhcyAkaW1nKXtcclxuICAgICAgICAgICAgJGltYWdlIC49IFwiPGltZyBjbGFzcz0nSW1hZ2VUYWdzJyBzcmM9JyRpbWctPnVybCcgYWx0PSckaW1nLT5kZXNjcmlwdGlvbic+XCI7XHJcbiAgICAgICAgfVxyXG4gICAgfVxyXG4gICAgXHJcbn0gZWxzZSBpZigkbXlGaWVsZCBpbnN0YW5jZW9mIFBhZ2VpbWFnZSl7XHJcbiAgICAkaW1hZ2UgPSBcIjxpbWcgY2xhc3M9J0ltYWdlVGFncycgc3JjPSckZmllbGQtPnVybCcgYWx0PSckZmllbGQtPmRlc2NyaXB0aW9uJz5cIjtcclxufSBlbHNlIHtcclxuICAgICRpbWFnZSA9IFwiXCI7XHJcbn1cclxuXHJcbmVjaG8gJGltYWdlOyJ9/!HannaCode

You MadeMyDay I followed your advice though I changed some a bit. Here's what I did in details: ~ created a template called "tags" without a (php) file ~ created a template called "tag" without a (php) file * "tags" template -> family: set "Allowed template(s) for children" as "tag" * "tag" template -> family: set "Allowed template(s) for parents" as "tags" ~ created a "tags" field with Type as "Page"; Input -> "Parent of selectable page(s)" as "Tags" (page), "Input field type" -> AsmSelect; "Allow new pages to be created from field?" checked. Set "template for selectable pages" as "tag". ~ created a template called "post" and added "tags" field in addition to its default "title" and "body" fields ~ created a hidden page called "tags" with template "tags" ~ created children of "tags" page as tags with a template "tag" ~ created tags.php file and put the following code in it to render the tags list: <?php include_once("./head.inc"); $tags = $pages->get("/tags/")->children->find("sort=title"); echo "<ul>"; foreach($tags as $tag){ //iterate over each tag echo "<li><a href='{$tag->url}'>{$tag->title}</a></li>"; // and generate link to that page } echo "</ul>"; include("./foot.inc"); ?> ~ created tag.php and put the following code in it to get the list of posts related to the selected tag: $thisTag = $page->title; $tagPages = $pages->find("tags.title=$thisTag"); foreach ($tagPages as $tp){ // iterate over the pages with that tag echo " <div class='teaser'> <h3>{$tp->title}</h3> <p>{$tp->summary}</p> <a href='{$tp->url}'>Read more...</a> </div>"; } include("./foot.inc"); ?> Thank you very much again MadeMyDay and please let me know if there is anything else to improve or fix.

First of all, create a template called "tags". It is totally fine to leave as it is, just a "title" field, no need for a PHP-file (for now). To be sure, only allow children with template "tags" in the template "family" tab. Then create your hidden "tags" page. Put same tags in it (that means: create children pages with your tags as title) if you like. Correct. Template for selectable pages is "tags". You can also define your hidden tags page as parent. No template file needed (for now). Not necessarily. or from the page select field itself (very convenient). So for that you need to have a .php file as template for the template "tags". First, create your tag list like this: echo "<ul>"; foreach($pages->get('/tags/') as $tag){ //iterate over each tag echo "<li><a href='{$tag->url}'>{$tag->title}</a></li>"; // and generate link to that page } echo "</ul>"; (totally untested, but you'll get it). Since the tag pages have no template yet, this will throw an empty page (or 404, don't know). So let us create a template for the tag pages, which lists all pages with that tag: // Beginning of your template here (head etc.) // select all pages with the tag of this tag page $thisTag = $page->title // Current clicked tag $tagPages = $pages->find("Tags.title=$thisTag"); // select all pages where page field "Tags" contains a page with title of our tag foreach ($tagPages as $tp){ // iterate over the pages with that tag // and generate some teasers (or what you like) echo " <div class='teaser'> <h3>{$tp->title}</h3> <p>{$tp->summary}</p> <a href='{$tp->url}'>Read more...</a> </div>"; } // Rest of your template here (footer, javascripts etc.) as I said, totally untested, but this should point you in the right direction.