Newbie question on field order

[Mark C]

I'm an old programmer (as in Algol, Fortran, Cobol, PL/I, C, Perl, etc.) just learning web development for an idea I have as a hobbyist/retirement project.  So the database side of things is no problem, nor is PHP per se', but the way everything fits together in ProcessWire is giving me trouble.  I realize this is likely a completely stupid question, but I don't understand some of the most basic mechanisms in ProcessWire, most likely because I'm starting web development, not from the ground up, but using a CMS framework, I guess.  I've gone through several of the tutorials, installed ProcessWire on both a shared hosting server and my personal WAMP (see how I'm already throwing around FLA's like I know what I'm doing?), and trying to build my understanding of the workflow, but I can't figure out why (seemingly contrary to some of the tutorials), I can move fields around on the home template that comes with the Intermediate Site Profile, even add new fields and include them on the Home Template and Page, but these changes never show up on the browser page.  If I make changes to content, titles, etc. of existing fields, they show up, but changing the order of them doesn't affect the output at all.  It appears that this is because that's all specified in the _main.php file, but I don't understand the capability of being able to move them around in the Templates, if they're hard coded in PHP...

I'm sure there's something somewhere in one of the tutorials I've already read that covers this and I just missed it, but at the moment I'm completely baffled as to what's going on...  If there's a "basic-er" tutorial somewhere on how all this stuff fits together, or a good overview of the concepts that I should go through first, I'd be grateful if someone could point me towards it.

[dragan]

Welcome to PW

Just very very quickly (it's past midnight now, and I should really get some sleep):

If you add a new field to a template, you have to add code to output that field.

Depending on direct or delayed output strategy (several echo() vs. $content .= concatenation and just outputting it once) - you need to simply add either

$content .= $page->my_new_field

or 

$page->my_new_field

"move things around in the template": PW doesn't care about your field order you're using inside your templates. You have to define yourself what you want to do with it - that's the nice thing working with PW (one of a million).

[alxndre]

Hi, first of all, welcome to the PW forums, and may I say what you are doing is exactly what I envision myself doing in retirement, still coding but for fun and learning.

9 hours ago, Mark C said:

I can move fields around on the home template that comes with the Intermediate Site Profile, even add new fields and include them on the Home Template and Page, but these changes never show up on the browser page.  If I make changes to content, titles, etc. of existing fields, they show up, but changing the order of them doesn't affect the output at all.

9 hours ago, Mark C said:

but I don't understand the capability of being able to move them around in the Templates, if they're hard coded in PHP

ProcessWire is not a WYSIWYG editor where you just move the items around and the change is reflected on the frontend. Moving around the fields in the template editor only changes their position when you are editing them in the page editor (i.e. Home > Edit).

Now to change the output, you do have to change how it is "hard coded" in the template files, as that mostly is how websites are written. There are "WYSIWYG" CMSs out there like Concrete5, where you can drag and drop the "sections" of a website, but I assure you, you're better off with PW as I was working with Concrete5 back in 2012 before finding ProcessWire and never looked back.

I hope this helped a bit, and that you enjoy working experimenting more with ProcessWire. Cheers.

 

[Mark C]

First, I want to thank you both for your helpfulness in taking the time to respond to a my question.  The diversity of participants, timeliness of responses, and overall demeanor of the forum here was actually a secondary reason I chose PW, after looking at literally dozens of CMS platforms (including Concrete5, FWIW).  (As a brief aside, I knew I didn't want "just" a WYSIWYG-based web development environment.  It's not my style, and I don't like the limitations, inefficiencies, etc.  Ryan's ProCache module seems particularly impressive to me, on the efficiency front...)

Second, I want to be clear that my next questions/statements are in no way meant to be argumentative or deprecating, either to either of you, or to PW itself.  I know that probably goes without saying, at this point, but written communication often has the drawback of loss of real intent, and I want no misunderstandings - I have a feeling I may need to feel welcome here...

I have to confess some amusement and nostalgia when I read your replies, because it's the sort of thing I've said many times when training programmers, with respect to why sometimes C (or even assembler or machine language) is sometimes selected over one of the myriad other choices available today that are called (or used to be called) "fourth-" or "fifth-" "generation" languages.  However, at this point in my lack of understanding of PW, the comparison ends there, because I don't yet see the value of (and thus the time spent coding) a GUI that doesn't affect anything other than the behind-the-scenes view of the developer.  I do agree there's considerable potential value there, but I'm not recognizing it here in this case yet, possibly because I don't have a clue what I've taken on yet.  There's probably another corollary to my first/second- vs. fourth/fifth-generation language comparison that I'm missing here, and that's what I want a grasp of, I think.  (Please also keep in mind that I have no formal education in Computer Science, Information Technology, or Data Processing, as it used to be called, because none existed when I entered the work-force.)

The primary reason I selected PW was the purported flexibility and ease of developing any sort of solution.  If my business idea flies, there's going to be quite a few very varied sites to come from it and I'm going to end up engaging others to do a lot of it - for now, I'm having to stand up a demo myself, and PW just seemed to me to be the most intuitive way of organizing the various pieces in the process, to the extent that my limited understanding of it was capable of an informed decision, at least.  Now, as I'm getting started actually attempting to "flip the switches and turn the knobs", I see all sorts of switches and knobs that don't appear to do anything meaningful.  I know that this must be a case where "appearances can be deceiving", so I'm hopefully asking for some enlightenment at the right time so I don't make any decisions that cause me to waste a lot of time.

Perhaps, what I need now, depending on the responses I get to this little diatribe, is to go through another basic tutorial, or "philosophy behind PW" presentation, wherein it is compared to the "other way" of building websites, so I can understand this basic aspect of it clearly.  As I stated in my first post, I suspect that my issues stem from the fact that I'm coming at this opportunity to familiarize myself with PW from the exact opposite direction that most do...  At any rate, sorry for wasting so much of everyone's time with this level of verbosity, but I really do appreciate the efforts to get my head straight on PW and what it brings to the table!  Thanks again!

[theo]

Quote

GUI that doesn't affect anything other than the behind-the-scenes view of the developer. 

In my opinion, Processwire is mainly a tool for coders to develop back ends for their (noob) customers.

So developing the "behind-the-scenes view" is a part of the job, as well as creating the front end.

It has not much to do with your front end HTML, CSS, other than that it does not prevent you from doing what you want.

[Macrura]

It has been said here many times that PW is like a dream PHP/MySQL API with a free admin on top.

The ProcssWire admin has no explicit connection to the frontend unless you make it so.  You could for example have a completely hardcoded HTML frontend page, and an admin that does nothing but serve as a CRM tool. The frontend is completely up to you; You may be confused because it comes with a free/default/demonstration front end, but nobody really uses that frontend.

1 hour ago, Mark C said:

I don't yet see the value of (and thus the time spent coding) a GUI that doesn't affect anything other than the behind-the-scenes view of the developer

You will see the value of it when you have clients using the CMS for content management (from simple to extremely complex content), which is what the admin is for.

If you have clients who will never use the admin, and only the developer, well that is your own unique set of circumstances, and no assumption should be made that everyone else does it this way.

Therefore your definition of who is using the CMS admin is making a vast assumption, and you have also made the assumption that the admin is somehow 'behind the scenes' when in reality it can be behind the scenes, or it could be 'the scene'.

 

[alxndre]

3 hours ago, Mark C said:

I don't yet see the value of (and thus the time spent coding) a GUI that doesn't affect anything other than the behind-the-scenes view of the developer. 

You should note that while the template editor is mainly for the developer, the page editor where you actually put content is mostly for the users (writers, ads/seo managers,business owners, etc). So the value is that you could have a functional and customized content editor with just a few clicks. It is also important to note that ProcessWire is a content manager.

For me, and for most cases i think, this is much more "valuable" than a WYSIWYG front-end because while front-end design trends/frameworks come and go, the back-end would remain the same. It would be much more wasteful to support all of these trends/frameworks with drag-and-drop support only for them to be unpopular in a few months. And it's also been argued countless times that a well-crafted website design is many, many times better than a "customizable" but inescapably bloated front-end. I still cringe remembering the markup regurgitated by Dreamweaver and the likes. Not to say that the concept is without merit, but it does not fit all use cases, and goes directly against ProcessWire's unopinionated nature.

3 hours ago, Mark C said:

Now, as I'm getting started actually attempting to "flip the switches and turn the knobs", I see all sorts of switches and knobs that don't appear to do anything meaningful.

Would you mind giving other examples? I've been using ProcessWire for some years on a daily basis, and I haven't once thought, "hmmm, this doesn't do anything, we should just remove it".

That being said, each project is still unique, and if you think the way ProcessWire works is inadequate, that's where modules come in. Or other CMSs, for that matter. For me the strongest reason for choosing ProcessWire is simple: with what it does it does so well, and with what it doesn't it doesn't stand in the way.

[dragan]

Well, there are many tutorials out there. Since I don't know which ones you already have read, I'll just urge you to read (or re-read) these basic overviews:

http://processwire.com/about/what/
http://processwire.com/api/

The "holy trinity" (imho) in PW consists of:

• templates
• pages
• fields

The API glues it all together.

Once you realize how those things play together, it'll click.

Now, and this is what most people might confuse:

Pages inside the PW admin (page-tree) don't have to represent typical "web pages". Pages can be used for simply creating attributes for a select dropdown in a template, as a reference. They don't need to be published (publicly visible).

Templates can store any number of fields - if you're just building "normal" websites, these would be called "page type". But you can also control permissions with templates (and much much more).

The hierarchical page-tree seems simple at first (some folks might think "so what?"), but you can use the page/parent-children relations for all sorts of stuff, like categories.

If you're building web apps / sites for an international audience, you'll be surprised how simple and thought-out the multilang handling is made inside PW. Lots of systems force you to create a JSON/XML file for strings that are not directly editable in your template (button/form/JS strings). With PW, everything is editable right inside the PW-admin.

PW selectors are powerful. Everything is relational. You can query, fetch, cross-reference anything easily (fields, pages, sub.field.values etc.).

You can build your own custom modules or dashboards, and don't even bother with a "classic front-end". People have built huge CRM systems or similar where everything is happening only in the so-called backend.

For lots of people, the "click" comes when they realize how bloat-free PW is. It doesn't assume anything. It gives you lots of freedom, and people accustomed to frameworks with a steep learning curve, at first don't really see the benefit of it. Because most ppl tend to think "more complicated probably equals better".

So, perhaps ask yourself what exactly do you plan to build. Ask questions here, and we'd be happy to point you in the right directions.

Edited March 5, 2018 by dragan
slight edits / typos

[Robin S]

It is possible to output fields in your template file so that you can change the field order in your template and see the change reflected on the front-end.

You would loop over the template fields and then output the markup relevant to that field. You could do this with a long if/else structure to check the name and/or type of the field...

foreach($page->template->fields as $field) {
    if($field->name === 'title') {
        echo "<h1>$page->{$field->name}</h1>";
    } elseif($field->name === 'images') {
        // ...etc
    }
}

But it would be tidier to set up render files for each field (see here and here) and then output the markup with...

foreach($page->template->fields as $field) {
    echo $page->render->{$field->name};
}

 

Edited March 6, 2018 by Robin S
Corrected duplicated link

[Mark C]

6 hours ago, Macrura said:

The ProcssWire admin has no explicit connection to the frontend unless you make it so.  You could for example have a completely hardcoded HTML frontend page, and an admin that does nothing but serve as a CRM tool. The frontend is completely up to you; You may be confused because it comes with a free/default/demonstration front end, but nobody really uses that frontend.

That makes complete sense to me, and is definitely a point of clarification I'll ponder a bit as I mull all the other excellent suggestions - thanks!

[Mark C]

5 hours ago, alxndre said:

For me, and for most cases i think, this is much more "valuable" than a WYSIWYG front-end because while front-end design trends/frameworks come and go, the back-end would remain the same. It would be much more wasteful to support all of these trends/frameworks with drag-and-drop support only for them to be unpopular in a few months. And it's also been argued countless times that a well-crafted website design is many, many times better than a "customizable" but inescapably bloated front-end. I still cringe remembering the markup regurgitated by Dreamweaver and the likes. Not to say that the concept is without merit, but it does not fit all use cases, and goes directly against ProcessWire's unopinionated nature.

Would you mind giving other examples? I've been using ProcessWire for some years on a daily basis, and I haven't once thought, "hmmm, this doesn't do anything, we should just remove it".

I agree with your viewpoint - it certainly is true that having a tool that tries to support "the latest thing" isn't going to be nearly as useful as one that "just works".  It was that very thing that drew me to PW, but my difficulty was in trying to understand the rather "elaborate" mechanism on the back-end tool-set, which was completely disconnected from the front-end.  I see the potential value there - now I just have to dive in deep enough to see the specific value in my own situation, I think.  At any rate, I'm convinced that it's there.  Thank you for your assistance!

As for examples, I think they all revolved around templates:  Neither adding new fields, nor reordering existing ones had any effect on the output page.  Then, when I saw it was all hard-coded in __main.php, rather than home.php, I was even further bewildered.  As another poster said, however, it seems that part of the "demo" isn't really intended to be used...

[Mark C]

4 hours ago, dragan said:

<snip> Once you realize how those things play together, it'll click.

Now, and this is what most people might confuse:

Pages inside the PW admin (page-tree) don't have to represent typical "web pages". Pages can be used for simply creating attributes for a select dropdown in a template, as a reference. They don't need to be published (publicly visible).<snip>

PW selectors are powerful. Everything is relational. You can query, fetch, cross-reference anything easily (fields, pages, sub.field.values etc.).

You can build your own custom modules or dashboards, and don't even bother with a "classic front-end". People have built huge CRM systems or similar where everything is happening only in the so-called backend.

For lots of people, the "click" comes when they realize how bloat-free PW is. It doesn't assume anything. It gives you lots of freedom, and people accustomed to frameworks with a steep learning curve, at first don't really see the benefit of it. Because most ppl tend to think "more complicated probably equals better".

So, perhaps ask yourself what exactly do you plan to build. Ask questions here, and we'd be happy to point you in the right directions.

I snipped portions of your post, not because I didn't appreciate them, but for brevity.  I had looked at the tutorials you referred me to, but I'll do so again since you feel they're relevant to my questions.  As to your comment on Pages not being pages, I had read that, and I even remembered it, but I don't think it had clicked, at least not in the context that would have cleared up some of my confusion, so thank you for that, as well.

What I'm envisioning building, is a set of sites dedicated to the preservation of historic areas by means of promoting tourism to them and, thereby generating interest in them and support of their maintenance and protection - quite simple, really, in the grand scheme of things.  The content management requirements would be pretty simple, but calendaring for events and creation of "news" posts (as contrasted with full-blown blogging) would be a necessity. Obviously, the sites would be fairly graphics-intensive.  The people responsible for the content would be very non-technical, so ease of use, and probably the ability to do it from the front-end itself, would be important.

[Mark C]

1 hour ago, Robin S said:

<snip>

But it would be tidier to set up render files for each field (see here and here) and then output the markup with...

<snip>

Thank you - I found the information on the page you provided the links to VERY helpful...

[Robin S]

35 minutes ago, Mark C said:

Thank you - I found the information on the page you provided the links to VERY helpful...

Another community member helpfully pointed out that I entered the same link twice. I have fixed that now - the other link was supposed to be for a subsequent blog post that expanded on the field rendering feature: https://processwire.com/blog/posts/processwire-3.0.7-expands-field-rendering-page-path-history-and-more/#field-rendering-with-template-files

[Mark C]

3 minutes ago, Robin S said:

Another community member helpfully pointed out that I entered the same link twice. I have fixed that now - the other link was supposed to be for a subsequent blog post that expanded on the field rendering feature: https://processwire.com/blog/posts/processwire-3.0.7-expands-field-rendering-page-path-history-and-more/#field-rendering-with-template-files

Ah - they were more astute about your intent than I was - I thought they were links to different spots on the same page...  Thanks again.

Between you, all the other posts in answer to my questions, and even a very detailed PM, I've got hours of reading to do now...

[DaveP]

9 hours ago, Mark C said:

I've got hours of reading to do now...

...and if you need a break from reading, take a look at this if you haven't seen it already. It's a very old video that Ryan did for PW 2, but very much recognisable even now. It covers some of the content management aspects of the PW backend. 

 

[alxndre]

7 minutes ago, DaveP said:

It's a very old video that Ryan did for PW 2,

On an unrelated note, why don't we have more videos like this? This is the kind of thing that really grabs people's attention. I think the intro video for Vue.js was short and simple but effective enough to get people (at least me) excited. Is it beyond us as a community to work on something like this?  

[Mark C]

55 minutes ago, DaveP said:

...and if you need a break from reading, take a look at this if you haven't seen it already. It's a very old video that Ryan did for PW 2, but very much recognisable even now. It covers some of the content management aspects of the PW backend.

I had watched it, but it was at the very beginning of my survey of the CMS scene.  In other words, I needed to watch it again, because I got a lot more from it this time around.  Thanks for the tip.

@alxndre I'd sure like to see more content like this, obviously...  I'm not typically a video guy, because I find them frustrating in that you have no choice but move at the presenter's pace, but this video was very balanced in that regard.  There are a couple of PW tutorials (the very first one in the tutorials section on the Docs page, for example) that have animated gifs of certain concepts and I found those extremely effective.  With that approach, I was able to watch a gif repeatedly to see what was being referred to, if necessary, or not watch it at all if the still was enough, or if I already understood the information.

Also, I just want once again to thank each and every person who's contributed to this topic to assist me - it's been as encouraging as it has enlightening.