jordanlev

Hi, I want to "inject" certain variables into a certain template from a module. How exactly can I achieve this in my module code? (It's a Process module, if that makes any difference). Specifically, I need to be told by PW which template it is about to render, then depending on which template it is I want to be able to send some variables to that template (so in the template file itself, in addition to the usual `$page->whatever` fields, it would also have `$my_custom_var` etc. that was set from the module "hook"). Thanks! -Jordan

I'm curious what the general consensus is about using php "short tags" (e.g. "<?=" instead of "<?php echo") in processwire modules. I know that this presents issues for some people because the feature is not enabled by default on some servers, but since PW requires php 5.3 and maybe caters to a more technically-inclined audience, I'm wondering what the standard practice is. I searched through the codebase of PW core itself, and I only see "<?php echo", so I am guessing it's still best to stick to that. But maybe the module authors don't stick to that as much? Also when answering peoples' questions in the forums, do you try to stick to the full "<?php echo" instead of "<?=" -- because then you avoid one possible error that is unrelated to whatever they are asking the question about? Or does pretty much everyone have the short tags enabled these days so it's not much of an issue? Thanks! -Jordan

If you're comfortable building markup, then you should absolutely build your markup first and then convert it into CMS templates. (This is the nice thing about markup-agnostic CMS's like ProcessWire... they do not dictate any sort of structure on you). The general idea is that you will be creating "templates" for your site... so go through your design and figure out which pages are basically the same as each other and which are different. Generally, there will be 1 template for the home page, a few templates for generic interior pages (e.g. "full width", "left sidebar", "3 column"... totally depends on your specific design), then a template for special pages that are related to specific "things"... like individual news articles or individual blog posts or individual portfolio pieces or individual employees, etc. Each "template" consists of your overall site markup, interspersed with editable fields (content areas) -- in general, wherever you see "Lorem Ipsum" text in your design, you'd replace that with a field. Then you will also have some places where you have a little php code to output lists of pages (e.g. "list the 3 most recent news articles on the home page) -- but don't worry, it's not much php code and ProcessWire is very logical and consistent with how you interact with it so it is easier to understand than other systems (in my experience). To speak to your specific requirements: Brochure style / informational sites: Absolutely! This is where CMS's other than Wordpress really shine, because you don't need to shoehorn a brochure site structure into a blogging system. Multiple, editable content areas per page: Absolutely! This is the foundation of ProcessWire... it is entirely up to you to define which fields should be in which page templates (if you've used the "Advanced Custom Fields" plugin in Wordpress, you can think of ProcessWire being an entire CMS based around that concept). Portfolio functionality: Absolutely! Create a template for "portfolio" and set up the fields you want for it (a text field for title, a textarea/CKEditor field for the description, an images field for the photos, see below for "categories"). Latest portfolio items are displayed on the front page (e.g. latest 6): Absolutely! In your "home.php" template file, put some code like this: <?php foreach ($pages->find("template=portfolio,sort=-date,limit=6") as $page) { ?> <a href="<?=$page->url?>"><?=$page->title?></a> <?php } ?> See here for more about querying pages: https://processwire.com/api/variables/page/ Editable slideshow on the front page (text and image): Yep! Create an "image" field, name it "home_slideshow" (for example), and assign it to your "home" template. Then in the home.php template file, put some code like this: <div class="your-slideshow-container-class"> <?php foreach($page->home_slideshow as $image) { ?> <div class="your-slide-class"> <img src="<?=$image->url?>" alt="<?=$image->description?>"> <p><?=$image->description?></p> </div> <?php } ?> </div> <script> //Your slideshow script here... (or include it in your html <head> or down above the closing </body> tag... whatever) </script> See here for more about how to interact with image fields: https://processwire.com/api/fieldtypes/images/ (Also, if you want more complex content in each slideshow slide [more than just an image and a description], you could make it a "Repeater" field and include image, title, description, caption, link to page, etc etc.... as many sub-fields as you need for each slide) News / Blog functionality: Sure... this is where (for better or worse) you will be doing more manual work than in Wordpress. News is rather easy... just create a template for "news", and create a top-level "news" page on your site and have your site editors add new news pages under there. Use the processwire query interface to list out news pages on the top-level index page (like how we did with portfolios on the home page). For "Blog Functionality", what exactly do you mean? Check out Ryan's "blog profile" for a lot of examples on how to structure this kind of thing: http://modules.processwire.com/modules/blog-profile/ Latest news / blog excerpts are displayed on the front page: Oh yeah! Same idea as the portfolios (just change the "template" you're retrieving to "blog" or "news", if that's what you named those templates). Custom contact forms: This one is tricky. There is a paid plugin for forms: http://modules.processwire.com/modules/form-builder/ ... I've not used it myself, I'm sure it's nice (although it seems like it might be difficult to skin it with your own markup... not sure about that though because I haven't used it yet). Doing forms yourself could be possible with more work, for example: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/ . In general, this seems like a problem that has not been solved perfectly yet (outside of the paid plugin of course, which is surely worth the money if building a site for a paying client, but maybe not so much when just experimenting with a system as you and I are right now). One last note about categories and tags: This is a bit different than other systems. It seems that in ProcessWire, when you need custom stuff, you implement it as templates and pages. So you create hidden pages with sub-pages under them, and these act as sort of database records (kind of, I think?). Here is a great explanation of how to create a tags system using this method: https://processwire.com/talk/topic/3942-help-for-creating-tags-please/?p=38605 ...and also check out the aforementioned "blog profile" to see a working example of how this is implemented: http://modules.processwire.com/modules/blog-profile/ . Hope that helps! (Also note that I'm relatively new to ProcessWire myself... although I have a ton of experience with other CMS's... so hopefully others will pipe in with more detailed or accurate info if I've missed anything or gotten anything wrong).

Under the hood it's the same thing. But it requires a lot of fiddling with fields and templates to make it work the way I want it to work (which of course might be different from how you want it to work, and that's okay -- I think that is the great strength of ProcessWire, because it leaves things very open to doing them in different ways).

I work mostly with Concrete5, which also has this functionality you're looking for. Check out this forum thread where I asked the same question and got some details on how exactly to set up the PageTableExtended field to work the way I wanted it to: https://processwire.com/talk/topic/7477-strategy-for-flexible-content-types-in-a-template/ I'm currently working on a plugin/module that will handle all of that for you automatically... basically you will create "blocks" which are groups of fields, then you will have a mini-template for each block (so you can output the fields however you need to), and an "Area" field (a PageTableExtended field) you can add to templates. Site editors can then add any kind of "blocks" to those "areas" (exactly as you've described in your question). I'm working on it in my free time so not sure when it will be ready, but I've made great progress so far so hopefully in the not-too-distant future. (I really want to try out ProcessWire on a real site, but I can't go back to a system that doesn't have these flexible content blocks / areas after getting spoiled with them in Concrete5

This is fantastic information. The more I think about it, I think this is one of those cases where I just need to give up my pre-conceived notions of how to do it. @kongondo said it well: "How many people really care about pretty URLs in the backend?" ... this is very true But the technique @Soma shows is good to know in case I change my mind (or need it in the future for something else).

Oh, I did not explain that clearly. Yes, I will use "executeSomething()" for the "top-level" url of a certain controller (or data entity). For example, if I have something like "employees" and "joblistings", the I can have "executeEmployees()" and "executeJoblistings()". But within each of those sections, there are several different actions one might take... you might want to display the list of all employees or jobs, then be able to add a new employee or job, edit or delete an existings one. Ideally then my url structure would be /employees (to list all employees), /employees/add (for the form that lets you add a new employee record), /employees/edit/14 (to edit the existing employee record having id "14"), etc. So as you can see there is the need for several addition url segments. It gets even trickier if my data relationships are such that an employee can only exist under 1 job record... in this case I might have /jobs/27/employees/add (to show a form for adding a new employee to job #27). What I am hearing from your answers is that I should not rely on the url segments for this routing, but instead I must do something like /employees?path=edit/14 , or perhaps something like /employees?action=edit&id=14 (that is probably better now that I think about it). By the way, the "employees" and "jobs" is just for example -- I know that in ProcessWire I should actually instead create pages and templates to manage something like this. I guess this is why my issue does not come up often, because it can usually be bypassed by using PW's existing pages/templates/fields system. But since I am trying to create an editing interface that is for manipulating pages/templates/fields themselves, it is too confusing for me to wrap my head around how to use pages/templates/fields to manage themselves... so I am reverting to the method I am most familiar with.

Hi @Soma, You're "reboot" explanation is very clear and explains things quite well -- thank you for writing all that out, it is very much appreciated! I create a lot of "CRUD" applications in CMS dashboard, where you have lists of records, then you view sub-records of those, and you add/edit/delete... each of these operations requires its own form/page. And I am used to other systems where you try to map the URL's to the data entities (this is what I believe I meant by saying "REST-like routing", but I could be using the wrong term there... that's just how I think of it). Ruby on Rails is the big one, but since Rails was released it seems that almost all other PHP frameworks are using a similar style (CakePHP, CodeIgniter, Symfony, Kohana, Laravel, etc.). So that's what I meant by "more modern system"... not that PW isn't modern, but I do think that the lack of REST-like routing in the admin modules is definitely how things were commonly done before Rails, but it is not so common anymore. Not saying it is bad, just different I think I can easily recreate the routing style I am used to (along with sub-folders in my module for "controllers", "models", and "views"), and I just need to pass around the "path" as a querystring argument instead of looking at the actual URL segments. This way I can have as many url segments as I want, and I do not have to worry about the maxUrlSegments setting at all. Overall, I like that ProcessWire does not try to impose its own architecture on you too much (of course there is some but that is unavoidable in any system). Overall it seems to "get out of your way" which is very good for experienced developers like us who already have strong ideas about how we like things to work for us. Thanks again, I really do appreciate your help as I learn this new system!

Ah, very good to know that the urlSegments are only available if you have an `executeSomething()` method defined. So I guess I need to not use REST-like routing ("pretty urls") in the admin dashboard, and instead rely on a querystring "path" argument or something like that. Seems kind of "old-school" to me, but I guess it works, and the admin dashboard does not need to be SEO-friendly so it is not a major drawback (just requires some different thinking than what I'm used to from other more-modern frameworks). Thanks for the help!

@Soma, the urlSegments *do* work in process modules (I have it working right now, at least in ProcessWire 2.5 -- maybe this is a new feature?). In fact, if you follow the link that @kongodo posted, you will see that Ryan specifically says "PW doesn't pass any arguments to the execute() functions... rather you can retrieve them from $input->urlSegment($n) if you want them". @kongodo, thanks for the link, it is helpful. But it still does not answer my question about using $this->input->urlSegment1 == 'something' versus function executeSomething() ... why should I use one over the other? And if url segments are not the recommended thing to use for some reason, how exactly can I set up my modules that have a lot of different admin pages in them? How is this normally done in ProcessWire modules? I want to follow the best practices but I do not see anywhere that this is documented. Thanks!

@mr-fan, Thank you for your wonderful response to my question. I did not know about the "field dependencies" option (I saw it in the admin, but did not understand the use case for it... but now you have explained it very well to me!) I think that is a great solution for some sites. The only drawback, as you said, is users cannot re-order them above and below each other. The new module I am building uses the PageTableExtended field, and I would only expect to have 6-8 "block types" per site (if you remember in Concrete5, there are about 20 included with the core system, but most of those are not used by clients in my opinion and instead are there for system functionality like autonav, page_list, and search). I think you will really like the module I am building because it will fill that role of letting you set up some custom content blocks that your users can re-order on the page (drag up and down). As Soma says, it will not be good for a site with 1,000's of pages, but for smaller sites (like company or non-profit organization information site) I think it will be very helpful. Thank you again for giving me great info about how I can use ProcessWire. I really like the system so far and the community in the forums is very helpful. Cheers, Jordan

@Soma, thank you for your response. I understand what you are saying and it will be good to keep in mind that these things are best for smaller sites, not 100,000 pages. (For my purposes, though, this is okay because I rarely build sites with more than 50-100 pages in them, so for my customers they usually value an easy and flexible editing experience above "scalability"). And I am actually building my module for use with PageTableExtended... that is the thing that is allowing this to even be possible (if you read through that forum thread I linked to you can see that someone recommended that and that is what got me started on this journey).

@Soma, I just discovered the Repeater field. You may be interested to know that this field does something similar to what I'm trying to do -- it creates new templates and fields and hidden pages. Since the Repeater is a core PW module, it seems to me that using this technique is not actually bending PW in a way it's not meant to be used. On the contrary, I think this is actually using PW in the exact way it is meant to be used -- where everything is a page, template or field (kind of like records, tables, and fields of a database). I agree that this abstraction can be taken too far (basically building a database on top of a database on top of a database, etc.)... but since I am just leveraging the existing PageTable field type I am not actually building an additional layer on anything. And I think I've figured out how to solve my original question (or at least I am on the right track)... $form = $this->modules->get('ProcessField')->buildEditForm(); //Now, I can override specific fields or page attributes of the form, for example... $form->attr('action', 'add'); //overwrite form action Neat!

I am trying to build a module of the "process" variety (some custom admin dashboard pages). It looks like there is not much in the way of an MVC system or routing for these... from what I can tell my options for routing boil down to 2 options: execute(), executeSomething(), executeSomethingElse(), etc. The execute() method responds to the "top-level" url for my module (for example, http:// my-site.com/processwire/setup/my-module/). Any other methods whose names start with "execute" respond to a "2nd level" url (for example, executeSomething() responds to http:// my-site.com/processwire/setup/my-module/something/; and executeSomethingElse() responds to http:// my-site.com/processwire/setup/my-module/something-else/) Inside the execute() method, use $this->input->urlSegment1, $this->input->urlSegment2, etc. to retrieve the portions of the url under the "top-level" (for example, if the user visits http:// my-site.com/processwire/setup/my-module/something, then inside the execute() method $this->input->urlSegment1 would be "something" (and for http:// my-site.com/processwire/setup/my-module/another/thing , $this->input->urlSegment1 would be "another" and $this->input->urlSegment2 would be "thing"). Am I understanding the system correctly? If so, what is the purpose of having "executeSomething()" if you can just look to $this->input->urlSegment1 inside the "execute" method? It seems rather arbitrary, since there is no way to use "executeAnotherThing()" to respond to /my-module/another/thing (as far as I can tell?). Also, isn't it true that the url segments might be set to a different level on different sites? So if I'm building a module for others to install, how can I know that the site it is installed on even allows 2-, 3-, or more url segments under my top-level page? Are there any example modules out there that implement their own routing system that is more robust than the default way (or am I misunderstanding how the default way works and in actuality there is a way to handle more complex routes?) Thanks!

Hi @Marek, I understand what you are trying to do, and I too like to have full control over my form markup (this is a frustration of mine with almost every framework / CMS / form helper -- they always want to output the form markup in their own way and it is always different than I want it One idea you might try is this module: http://modules.processwire.com/modules/form-template-processor/ ...it lets you use piggyback on the PW admin interface for building a template and uses the template as a form (because really a ProcessWire template is a form if you think about it -- it has a bunch of fields). The two limitations on that are: 1) By default, it automatically outputs the form markup. 2) It only has 1 kind of validation possible ("required"). Problem #1 can be solved by not calling the $form->render() function as described in the documentation, but instead outputting the individual form fields yourself. I have a post about this here: https://processwire.com/talk/topic/1894-how-to-render-a-simpelt-inputfield-markup/?p=73109 You will see that the response to that post was basically "you should not do that because then other processwire modules cannot extend your form"... but that is not a concern in this case because you are not building an admin module, but instead just a custom form for the front-end of your site Problem #2 cannot be solved by using built-in ProcessWire functionality (because that kind of validation does not seem to exist in processwire), so you should just go ahead and include your valitron library to handle that. I hope that helps!

Hi @mr-fan, Thank you for your response. Can you please explain more about how you were able to build your sites without the flexibility of C5's blocks and areas system? To me, the lack of such a system in ProcessWire is what holds it back from being able to serve as a good CMS for the kinds of sites I build (mostly marketing/informational sites with very custom designs). I understand that if the site you are building has a rigid data structure (almost like a database, like the "Skyscrapers" example site that ProcessWire has), then the limitation of having to pre-define the fields per template is best... but for so many of the sites I build, it would be very difficult to restrict our clients in that way. When we build wordpress sites (which we never choose on our own, but sometimes clients request it), we use the Advanced Custom Fields plugin to approximate some of the custom field aspects of ProcessWire, but what happens is we wind up creating a TON of different templates just to accommodate the different design options our clients might want. We have really found that a few custom blocks in Concrete5 go a long way to giving our clients the flexibility they need without allowing them to mess up the design too bad (this is why I have created the "Designer Content" addons in C5 -- to make it really easy to set up these custom content interfaces in a way that guides clients to enter just what they need and keep our design markup working well). I see that a lot of people here on the ProcessWire forums like to use "Hanna Codes" in the CKEditor to achieve this kind of flexibility, and I think that works okay for some people if they are technically inclined. But in my experience, things like that are a terrible user interface for most non-technical people and it causes a lot of support headaches for us. If you are making ProcessWire work for your needs, though, I really am very interested in hearing more details. As for the implementation of a block system in ProcessWire, it actually is doable now with the new "PageTable" field type that is included in PW 2.5 (see the forum thread I linked to in my original post for details). The only problem with it is it requires a LOT of setup to make the fields and templates work in the right way. So I am trying to build an admin interface that provides an easy user interface for automatically managing all of the settings. It doesn't add any new functionality to ProcessWire itself -- it is just a nice front-end to existing features of the ProcessWire core system. I am going to keep working on this, because I think once it is done people will be able to see how useful it is (and how it actually fits into the ProcessWire system quite nicely -- because it's just fields and templates, like everything else in the system). I wish I could get more technical help on how exactly to interact with the admin interface, but perhaps my question is too hard to answer in a forum and I just need to keep trying myself to make it work. We'll see how it goes

Thanks for your input, Soma -- I will take it under advisement. However, I still would like to build what I'm trying to build so I can see for myself if it's feasible. I think what I'm trying to build is hard to explain in words (especially if you've never used a system that is block-based, like Concrete5 -- where I am drawing my inspiration from), but once it exists as an actual module you can interact with it will become a lot clearer. All I am doing is creating a few extra templates with some fields for each one. Are you telling me that ProcessWire is not capable of having 6-12 additional templates, each of which has 1-6 fields in them? I would find that hard to believe since everything I've seen of ProcessWire indicates that it is perfectly capable of having many templates in 1 website and of course every template has slightly different fields in it. I thought the whole purpose of ProcessWire was to be able to have any fields you wanted in each template, instead of assuming you just have a "title" and a "body" like in wordpress?

No, not a new input per page -- rather, a new set of fields per template. (The same exact thing one would do when creating a new template themselves... set up some fields and add the fields to the template... but I want to automate the specific settings of all those because there are so many things that need to be configured in just the right way in order for things to work the way I want). BTW, If you think that's not a good idea, that's fair, but could you at least explain your reasoning behind it? As a newbie to processwire, understanding the rationale for different approaches will help me learn a lot more than just getting a "yes" or "no". Thanks!

Hi, I am attempting to create a process module that is basically an admin interface for configuring other fields and templates. (I am trying to automate the setup and management of flexible editable "areas", as discussed here: https://processwire.com/talk/topic/7477-strategy-for-flexible-content-types-in-a-template/ ). I've got a lot of it figured out, but need some help with the "configure fields" section. In essence, what I'm trying to achieve is to have a separate page in the admin for managing some fields. So I want to use all the built-in functionality that exists on the normal Setup > Fields admin form, but include it in my own separate admin page. I have the process module set up and I know how to respond to certain url, but once a user is at my url how can I show them that "fields" form for a particular field? (Assuming I have the field id). Also, I also want to do something tricky when I display that form: instead of the usual "name" field, I want to show the user a different textbox field (which I'm calling "handle")... the user enters a "handle" into that field (which I just made up myself... it's not part of processwire) and then on the back-end when I process the form submission I will take what the user entered for the "handle" and prefix it with another string and use that concatenated value as the field "name". So I want to hide the "name" field, add my own new field in its place, then programmatically generate the "name" myself *before* the form is validated and saved by processwire. Any thoughts on how to achieve this? Thanks! -Jordan

You might want to read this thread for how to use ProcessWire's built-in form builder: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/ Although note that it does not handle any validations other than "Required", so you might want to still use the Valitron library as a separate validation step.

The Robert Reich site you linked to is a straight-up blog, which is the kind of site perfectly suited to wordpress. You can absolutely build a site like that in ProcessWire too though (as well as sites that are less blog-y ... which is where a system like ProcessWire will really shine because it won't lock you into a blog-like page structure). I would say the big difference between wordpress and processwire is that wordpress has some assumptions baked into it... it assumes that most pages on your site are blog posts, it assumes you have 1 primary area for content per page and then some miscellaneous "widgets" that appear on every page (in the sidebar, for example), and it assumes that your templates have a header, footer, and a few different types of "interiors" (post, page, etc). The thing about processwire is that it imposes very few of these kinds of assumptions on you. Really the only assumptions it makes is that you have pages of various different "types" (different types could be different visual layouts and/or different pieces of content). So you don't just have "posts" and "pages"... you can have whatever you want. Another big difference is wordpress's assumption that there is 1 primary piece of content per page... in processwire there is absolutely NO assumption about what content lives on each page (except for 1: every page must have a "title"). If you have ever used the wordpress plugin "Advanced Custom Fields", then you can kinda-sorta think of processwire as an entire CMS based around the ACF mindset. SO... to recreate that Robert Reich site, you would have a "blog_post" template, a "home" template, and an "archive" template. The "home" template is only used on 1 page (the home page), and the "archive" template is only used on 1 page (the archives page). The "blog_post" template is used by all other pages. In terms of the page structure (like the sitemap tree), you'd probably have the home page at the top, and "posts" page underneath (which could serve as the "archive" page and also a parent page for all blog posts). The home page template would have the following fields: bio (textarea w/ CKEditor) books (Repeater field) TV Appearances (Repeater field) Movie (video) Slideshow (some kind of slideshow field, or an image field with your own front-end slideshow javascript code) videos (repeater) The home page template would output all these fields in the appropriate places, and then in the middle of the layout it would use ProcessWire's "query" to display the 10 most-recent posts. For the "archives" page, you also use PW's query API to retrieve ALL posts, and in your php code you can segment them by month/year. For the blog post pages themselves, you have a "body" field for the primary content (a textarea with CKEditor). Note that the stuff on the left and right sidebars of the home page actually appear across all pages... so these are more like "global content" areas or "snippets" or "widgets"... I'm relatively new to ProcessWire myself so I'm unsure what the best way to achieve re-usability of these is (hopefully someone else can chime in about that... perhaps creating a dummy page in the sitemap that holds these and then the template retrieves the fields of that dummy page and outputs them?). There's also an RSS feed page and a 404 page template you'll want... you can copy these from the default site profiles that PW gives you upon installation. So that's a high-level overview (from someone who is relatively new to ProcessWire, which is probably both good and bad in terms of explaining things Let us know how it goes!

I think having a step debugger is incredibly valuable, especially when trying to understand a system you didn't create yourself (e.g. ProcessWire, or any CMS or framework you're building on top of). I develop on a mac, and my preferred solution is xdebug (which comes preinstalled on MAMP these days) with the very light-weight and simple "MacGDBp" app (which is like the GUI front-end for xdebug): https://www.bluestatic.org/blog/category/macgdbp/

I am a newbie to ProcessWire, but a very experienced web developer (using a variety of other CMS's and frameworks). I think the big picture here, as others have stated, is that PW doesn't really dictate any particular style for structuring your templates -- what you're seeing in the intermediate profile is just an example of how some people choose to do it. I personally do not like that method at all, because I build a lot of sites with very custom designs, so the markup I get from designers is very important and usually I like to keep my CMS templates as close to the original markup as possible. I do not like putting html into variables, and I do not like treating my template output as some kind of machine that generates markup. On the contrary, I like to take the markup I'm given and intersperse content variables in the slots they belong. But I understand that a lot of other developers are not as design- or markup-focused, and instead prefer to treat the html as just something outputted from their own system. My least-favorite CMS I've ever used is Drupal, because the whole thing is based on this mindset of contorting your markup to work within its system of outputting stuff. My most-favorite CMS's are ones that just give you the data and let you output it any way you want (CMS Made Simple, Concrete5, ProcessWire, etc.). So I don't really have a point here, other than wanting to pipe in and let you know that you are *not* doing anything wrong or thinking about anything the wrong way! You should just ignore the way things are done in the intermediate profile (what the PW folks are calling the "delayed output method") and instead stick to the way things are done in the basic profile (what the PW folks are calling the "direct output method"). There is no "eureka" moment really, other than understanding that some people see the world in different ways So if there were one thing I'd want to change about how these profiles are done, it's just that I think calling one "basic" and another "intermediate" gives the wrong impression -- I think it would be better to refer to them as "simple" versus "concentrated", or "designer-focused" versus "programmer-focused", or "markup-oriented" versus "architecture-oriented" -- some way to indicate that they are two different ways to do things and one is not more "advanced" or "better" or "farther along the path of learning" than the other. Just my two cents though.

Martijn, Can you explain to me how you can create templates for different fields? I would be interested in knowing this, but as a PW newbie I am unsure where to begin. Thanks!

Hi Martijn, I think the OP was possibly asking about front-end forms, where the markup is really important, but tying it into the PW admin system is not. Seems that the form builder api can still provide some value there, even though that's not its primary use-case. But yes, I understand how if you are building an admin page that it would be important to hook into the larger PW system so that other people can program against your own module in the future.