Vigilante Posted February 26, 2014 Share Posted February 26, 2014 Hello, I've been playing with PW for a couple weeks and reading through the site and watching some videos etc, but I wanted to ask a few specific things. One thing I want to know is, what is the best way to start a completely blank project? When I unzip PW into a web folder, I spend more time renaming things, removing things, file shuffling, editing existing pieces, than if I could just start with a blank project. What is the best way to do this? Do I just empty everything from the templates folder? Not sure what is required and what is optional. Second, I build websites in PHP/MySQL and mainly work on administrative websites, or sites that are heavily user-access controlled. That said, almost every page in my website has very different content that does not seem to lend itself to the template/pages system of PW, unless I'm doing it wrong. For example, on one website there is a "Documents" top-level page with a few sub-pages like "Policies" and "Forms" and "Media". All the pages have their own landing page. So for example if I click Documents, it will not only show the three subpages in a submenu, but it will show a main page as well with things like statistics, recent downloads, recent updates etc. All 4 of these pages would be quite dynamically built, with information pulled from a database and assembled on the fly. How do I do this in PW? I can write lots of PHP inside templates and do a lot of PHP/MySQL work there, but I can't do that in Pages. So I'm confused, it sounds like for my sites all my "pages" are actually templates because that is where I do a lot of dynamic PHP stuff, and then I match each template to one page to show it. This doesn't seem right. Here is what my brain is saying should happen: I would create one single template, just one, because all the pages of my site share the same general symantic structure and main menu system, logo, header, footer, login box, search box, etc. Then I create lots of pages for each section and sub-section of the site. However, I can't do all my PHP work inside pages, I can only put basic info inside fields, which isn't even all that helpful, but seems to be the driving benefit of PW in the first place. In other words, I don't want to fill in some predefined fields for all of my pages, I need to write a crap ton of PHP code for each one of my pages. How do I do that? It seems that Pages are not actual files, but Templates are, so I can code in templates but can't code in pages. I don't know what I'm missing here. The idea is that when a page loads such as Home->My Profile, this is where a user is logged in and goes to edit their profile. In a normal PHP project, I would log them in, and use some kind of dynamic "profile.php" file that would be included in the main template, then I would grab all the user's info from a DB and let them edit it. The profile.php page would probably call some PHP class file, use a bunch of methods and so on. In a normal PHP project, everything would start with an index.php file, which would then build the template structure, and finally include the "page" PHP file for the dynamic information that needs to be shown.I'm not sure how this structure works for PW. Do I create separate "templates" for every dynamic page on the website so that I can do PHP coding in them? If I do all my coding in the template, that what is the purpose of the page? And it's also not good to have 25 template files all duplicating basic symantic structure. I like to write DRY code so the PW template/page system is not making a lot of sense to this PHP programmer. Where do I write my PHP code for all my pages in a PW site? Thanks for any advice! Link to comment Share on other sites More sharing options...
Joss Posted February 26, 2014 Share Posted February 26, 2014 Hi and welcome Its easier to sort of go through this in a very boring way ProcessWire has a fairly basic construction: Fields > Templates > Pages As you would have already noticed. Firstly, it is important to realise that Templates and Template Files are not the same thing. Templates are your way of grouping fields together and template files are for markup for displaying pages. PW has no practical limits for the amount of fields, templates, template files and pages you create, so really you can do as many variations as you need - it really wont matter. The API in ProcessWire allows you to manipulate the field data associated with either the page you are currently viewing ( so $page->title, for instance) or it allows you to get or find fields from other pages or groups of pages. One of the most important areas for you to look at in the API is probably the section on selectors as this will give you a lot of details about relationships and retrieving field data. So, looking at Profiles for the moment. You might create a file in sites > templates called profile.php Then in the backend, you would create a new template - it will show that profile.php is available as a template file and you would choose that, obviously, then give your template a name - profile would be good! You now create a bunch of fields that you want to use for the profile. In some ways this is a bad example because there is already a template in the system for users, but we will pretend for the moment there isn't! However, when you create a template in the backend, after you create it you can associate other template files with it, should you wish. Add your fields to the profile template and you are half way there. From this point on, it is simply a case of using PHP and the API in profile.php to create what you need - and it is much simpler than starting from scratch. The API is very powerful and will do a lot of the work for you, while leaving you to do whatever layout you wish. That template and template file combination can now be used for creating thousands of profiles. When you link to one of those profiles, it will use the template and associated template file to render the data. The template file can be used for both displaying data and for creating input forms for editing data. (Other people can give you more of a lead about that). Now, with other pages, if you need to create completely different templates for each page because they are all completely different, then that is what you do. Not a problem. Though remember that any field can be used in any template. So, if all your templates need Title, page_meta, mani_text and so on, then you can reuse field as you wish (note, you can only have one instance of each field in a template, for obvious reasons - so if you need two textareas, you will need to create two textarea fields) The point with PW is that apart from following the relationship between fields > templates > pages, it is flexible enough for you to work however you wish, more or less and very fast once you get the hang of it. 5 Link to comment Share on other sites More sharing options...
kongondo Posted February 27, 2014 Share Posted February 27, 2014 Hi Vigilante, Welcome to PW an the forums... Adding to what Joss said, if you know your PHP, you will absolutely love PW...but you only need the PHP basics to work with the system... Think of templates as controllers and template files as views...You can even have one template, one main template file and several other .inc or .tpl to help with views. See this thread: http://processwire.com/talk/topic/740-a-different-way-of-using-templates-delegate-approach/ All your PHP code goes inside template files. A page is mostly something abstract...it just helps you to input content which you can later retrieve.... Very important to remember in PW - it is very flexible; there is no one coding style! So, if you look at different "profiles" - see modules section, as well as the default install, plus other examples on the forums, you will notice differences! Blank profile: http://mods.pw/19 Sorry, the above is somewhat erratic. You being a programmer, I'd say, get the basics of PW first. If you get this - http://processwire.com/api/ - you can do anything....I'd even dare to say, forget the videos for now...you are a coder, so look at some code..., try things. PW gives you the tools to accomplish a lot, easily, fast and consistently... -------------------- I'll probably edit this post in the morning 5 Link to comment Share on other sites More sharing options...
diogo Posted February 27, 2014 Share Posted February 27, 2014 Hi vigilante, welcome to the forum! One thing I want to know is, what is the best way to start a completely blank project? When I unzip PW into a web folder, I spend more time renaming things, removing things, file shuffling, editing existing pieces, than if I could just start with a blank project. What is the best way to do this? Do I just empty everything from the templates folder? Not sure what is required and what is optional. There is a blank profile http://modules.processwire.com/modules/processwire-blank-install/ Second, I build websites in PHP/MySQL and mainly work on administrative websites, or sites that are heavily user-access controlled. That said, almost every page in my website has very different content that does not seem to lend itself to the template/pages system of PW, unless I'm doing it wrong. For example, on one website there is a "Documents" top-level page with a few sub-pages like "Policies" and "Forms" and "Media". All the pages have their own landing page. So for example if I click Documents, it will not only show the three subpages in a submenu, but it will show a main page as well with things like statistics, recent downloads, recent updates etc. All 4 of these pages would be quite dynamically built, with information pulled from a database and assembled on the fly. How do I do this in PW? I can write lots of PHP inside templates and do a lot of PHP/MySQL work there, but I can't do that in Pages. So I'm confused, it sounds like for my sites all my "pages" are actually templates because that is where I do a lot of dynamic PHP stuff, and then I match each template to one page to show it. This doesn't seem right. A site like this will be more complex to build with any tool. If pages are very different, one way is to have almost a template per page. if there are things in common, you can use the same template and use includes or functions on a common file. If the differences are minimal, you can do simple checks inside your templates for the page ID or any other characteristic this page may have that differentiates them from the others (a field. or the person that is looking at it, or the language, or whatever) Where do I write my PHP code for all my pages in a PW site? You write it on template files, but has I told above, you have to be a bit clever about doing it. If the site really asks for it, either because of each page needing different fields, or because the code just need to be too different for each page, you can also go the 1 page / 1 template route of course I've seen that Joss and Kongondo also answered already, but still didn't see their answers. I bet they are loooooooooooooooong!!!! edit: I was right about Joss. Kongondo is not in a good shape today 6 Link to comment Share on other sites More sharing options...
Joss Posted February 27, 2014 Share Posted February 27, 2014 I thought I was being brief! There was loads I left out, like .... Er, yeah, okay. I will go to bed now. Link to comment Share on other sites More sharing options...
teppo Posted February 27, 2014 Share Posted February 27, 2014 One more addition to answers above: you should take a look at Hanna Code module. It allows you to pull snippets of arbitrary PHP code into pages. This is what I've used to solve more complex needs, pages that need weird snippets etc. Typical issue with Hanna Code is that you won't be writing the code as files, so they won't be in your version control system etc. One way to solve this is to create Hanna Code snippets that include code from files and/or actually render pages. There's quite a lot that this little beauty can do, actually. Many of us "long-time PW users" have developed our own ways to work with PW. I'm using something similar to Zend Frameworks approach, with controllers, view scripts and partials, for an example. This is both a curse and a blessing with extremely flexible system like ProcessWire; you can create your own way to work with it, but especially if you're working on more complex stuff you'll also pretty much have to do that 5 Link to comment Share on other sites More sharing options...
renobird Posted February 27, 2014 Share Posted February 27, 2014 That said, almost every page in my website has very different content that does not seem to lend itself to the template/pages system of PW, unless I'm doing it wrong. I'm having a difficult time imagining a scenario where templates/pages wouldn't be flexible enough to accommodate anything. It's really a matter of the logic in your templates. And it's also not good to have 25 template files all duplicating basic symantic structure. I like to write DRY code so the PW template/page system is not making a lot of sense to this PHP programmer. You can setup your templates to be as DRY as you like. There's no need to duplicate markup. Take a look at the delegate approach kongondo linked above. You may also want to check Ryan's blog profile for some ideas. There is also this discussion that may be of interest. When I first starting using ProcessWire it did take a bit to get used to the idea that there is no set way to do things. I think you'll find it's incredibly flexible, and can accommodate almost any approach. Oh, and the community here is exceptionally friendly and generous. 4 Link to comment Share on other sites More sharing options...
Joss Posted February 27, 2014 Share Posted February 27, 2014 Oh, and we are cheap too. Link to comment Share on other sites More sharing options...
adrian Posted February 27, 2014 Share Posted February 27, 2014 But not easy 1 Link to comment Share on other sites More sharing options...
Vigilante Posted March 3, 2014 Author Share Posted March 3, 2014 Thanks for the thoughts and suggestions. I will form a longer reply when I've browse the various things linked in here. As a followup, is PW set up so one can have a classic MVC setup? As a second followup, I'm confused about pages being used as data objects. In other words, in the skyscraper example, instead of storing your architects in a database, he has one page for each name. Same thing with cities, one page for each city. This doesn't seem scaleable. Why would I take data that is clearly suited for a database and make them pages instead? This would be like, I dunno, Amazon storing every book they sell as a page? Or every author? I'm not clear why he would store architects OR the cities as pages instead of database tables. Is this how PW is supposed to work, replacing DB tables with long page listings? thx Link to comment Share on other sites More sharing options...
adrian Posted March 3, 2014 Share Posted March 3, 2014 MVC Options: http://modules.processwire.com/modules/spex/ http://processwire.com/talk/topic/4892-an-almost-mvc-approach-to-using-templates/ http://processwire.com/talk/topic/3587-templates-mvc-recursion-etc/ http://processwire.com/talk/topic/5031-get-started-with-pw-mvc-module-by-harmster/ A few links to get you going on understanding what a page really is: http://processwire.com/talk/topic/5059-2-question-about-pages/ http://processwire.com/talk/topic/5325-database-table-versus-pages/ http://processwire.com/api/variables/pages/ http://wiki.processwire.com/index.php/Page_Field 2 Link to comment Share on other sites More sharing options...
kongondo Posted March 3, 2014 Share Posted March 3, 2014 ......As a second followup, I'm confused about pages being used as data objects. In other words, in the skyscraper example, instead of storing your architects in a database, he has one page for each name. Same thing with cities, one page for each city. This doesn't seem scaleable. Why would I take data that is clearly suited for a database and make them pages instead? This would be like, I dunno, Amazon storing every book they sell as a page? Or every author? I'm not clear why he would store architects OR the cities as pages instead of database tables. Is this how PW is supposed to work, replacing DB tables with long page listings? thx .....a page is a db record ...too. Yes, you need to read up first. And, it seems you are getting confused between the page tree (just a visual representation of some db entries) and the frontend website pages (views)....Pages are infinitely scalable....Oh, btw, PW will work just fine with you storing your data NOT as pages; you just won't have access to parts of the great Page API in that case....I need some coffee, there could be mistakes 1 Link to comment Share on other sites More sharing options...
diogo Posted March 3, 2014 Share Posted March 3, 2014 But to resume all that reading "a page is not a page", it's an object within a tree structure (just as in json) with a URL (that can be available on the website or not) 3 Link to comment Share on other sites More sharing options...
kongondo Posted March 3, 2014 Share Posted March 3, 2014 .....and a tree structure is one way of viewing it..[the object]....(it makes most sense to view in a tree...)....you can also view it in a grid/table.... 1 Link to comment Share on other sites More sharing options...
Pete Posted March 3, 2014 Share Posted March 3, 2014 If you look at the database you'll see that each field is it's own database table. This is usually the first thing to freak some people out a bit when using ProcessWire (I was confused when I started!), but when you understand the power of pages (and that a couple of joins behind the scenes can often be more efficient than pulling in a massive table whether you wanted the data from every field or not) it will start to make sense. ProcessWire has been tested with at least tens of thousands of pages (and I think well over 100,000 as well) and performance doesn't seem to be a huge issue. As with any programming, as long as your selectors (PW's version of DB queries) are sensible then you should be fine. There are also a number of caching options such as MarkupCache, template caching and the ProCache module that can drastically speed up your site in a variety of ways - where appropriate. The beauty of pages is that fields can be re-used. The Body field can apply to many templates, but it's still just one table in the database. Same with any other field. You also get the ability to use Page fieldtype which let you reference other pages cleverly and which you wouldn't easily be able to do otherwise. The bottom line I guess is, there wouldn't be this number of people active in the community if it didn't work well. If it didn't work for the range of sites we've built with it, we wouldn't be using it. Yes, there is a lot to get your head around, and I found that there was a lot of baggage I'd brought from other CMS's that I had to un-learn, but once it all clicked I never looked back. Building a website in a fraction of the time I used to be able to? Yes please! 6 Link to comment Share on other sites More sharing options...
Pete Posted March 3, 2014 Share Posted March 3, 2014 In fact, here are a few posts on large-scale websites: http://processwire.com/talk/topic/4349-thousands-of-pages-one-site-with-multiple-pages-or-one-install-with-multiple-sites/?p=42909 http://processwire.com/talk/topic/1527-largest-project-performance-multi-server/ 1 Link to comment Share on other sites More sharing options...
Joss Posted March 3, 2014 Share Posted March 3, 2014 Just sneak this old thing in: http://processwire.com/talk/topic/2296-confused-by-pages/ 2 Link to comment Share on other sites More sharing options...
kongondo Posted March 3, 2014 Share Posted March 3, 2014 Just sneak this old thing in: http://processwire.com/talk/topic/2296-confused-by-pages/ I thought we had already sneaked it in....didn't even bother to confirm since it's the first one I normally go for...assumed it was one of @Adrian's links above Link to comment Share on other sites More sharing options...
adrian Posted March 3, 2014 Share Posted March 3, 2014 Sorry about that - I did have a quick look for that, but missed it. Apparently I wasn't searching with: http://processwire.com/talk/topic/4510-field-type-json/?p=44317 4 Link to comment Share on other sites More sharing options...
kongondo Posted March 3, 2014 Share Posted March 3, 2014 I thought that looked familiar, hehe! Link to comment Share on other sites More sharing options...
teppo Posted March 4, 2014 Share Posted March 4, 2014 But to resume all that reading "a page is not a page", it's an object within a tree structure (just as in json) with a URL (that can be available on the website or not) This may be a bit off-topic (nothing new from me), but I remember someone saying that "Page" makes much more sense than "Node" (for an example) for web use, and I really do agree with that. Still it's interesting to see how people not used to ProcessWire's jargon (and often coming from other systems and/or custom-built applications) get confused here. CMS/CMF such as ProcessWire has to manage content as nodes / items / pages / rows of some form and in this case those items are called Pages. They're not that different from Nodes in Drupal or Posts (and, these days, a whole bunch of different "post types") in WordPress.. or even from simple database rows. The main difference between database rows and Pages, of course, is that Pages have mostly web-related helpers (methods) attached to them and the built-in ability to pull content automagically from multiple tables. Sure, you could say that Pages are objects and thus have some overhead from there, and you'd be absolutely right. Then again, it all depends on your use case and what really matters for you. Most things built in ProcessWire could be considered "web sites" and web sites usually consists of (surprise!) Pages. Makes sense, huh? It is also important to note that you don't actually have to use Pages for everything. Saying "in ProcessWire everything is a Page" is misleading. It's true for the bulk of everything built with ProcessWire, but there are exceptions. For my Version Control, Changelog and Login History modules, for an example, I chose another route: a custom database table. In my opinion custom database tables are better option in some cases, but this way (like Pete already pointed out) you won't be able to use ProcessWire's selector engine; you'll have to write all your queries as plain, old SQL instead and route them through $db (MySQLi) or $database (PDO) objects. Doable, but potentially less secure (with selectors there's no risk of SQL injections, for an example) and more complicated. There's also the option of creating custom Fieldtypes. Each Fieldtype defines it's own schema, so this is very viable alternative to custom database tables. This way you'll still be able to work with native selector engine, but you'll get some of the benefits of plain database tables also. Ryan's Events Fieldtype is a good example (and starting point) of this. ProcessWire sets very few limits on the way you work. Want custom tables? Sure, go ahead, do it. Want to use Pages you can add fields to later with ease, edit with built-in admin tools and find using selectors? Sure, we can do that too. Combination of both, pages with fields of custom type and schema? No problem, we've got you covered. .. and this is one of the main reasons I love ProcessWire. 9 Link to comment Share on other sites More sharing options...
adrian Posted March 4, 2014 Share Posted March 4, 2014 Really great writeup teppo - I feel like this should be posted somewhere upfront. As you so eloquently stated it really is PW's ability to use pages and custom field types with the selector engine, but then if you really need it, it's not difficult to integrate full custom database tables with SQL queries. It's that combo that sold me too! Link to comment Share on other sites More sharing options...
pwired Posted March 4, 2014 Share Posted March 4, 2014 Following this thread for days now. This whole thread has become golden info for newbies and starters. Copied the thread link to processwire cms insights and copied teppo's pages post to pages in processwire. http://processwire.com/talk/topic/4173-grouped-forum-posts-links-articles-tutorials-code-snippets/ 2 Link to comment Share on other sites More sharing options...
Vigilante Posted March 8, 2014 Author Share Posted March 8, 2014 OK here is a project I've got going as a training example. Think of it as a company private intranet. I notice in PW you get just one top-level page. I happened to rename mine to "Core" as that is the name of this intranet. This top-level page seems to be what loads at the top-level URL as well. For example if I go to example.com it would load content from Core. However, I need my website set up so that the main menu is something like "Home | Documents | Media | Templates" for example. So here is my first challenge. I create those four pages as sub-pages of Core. They will in turn contain sub-pages of their own. Such as Documents->Employement | Policies | How-to | etc. Even the "Home" page will have sub pages that are more related to the user, such as Home->Profile | Calendar | Messages | Projects | etc The problem I'm having is that by using a Page called "Home", with sub-pages, I now have two "home" pages. In other words, there is now example.com, as well as example.com/home. Technically these should both be the same thing, but they aren't. I have to actually click the Home menu to open the /home/ URL, while typing the domain name example.com loads the information within Core itself. I'm not sure how to make Core and Home be the same page essentially. And if I were to delete the Home page, and put those sub-menus directly under Core, how do I distinguish them from the other top-level menus like Documents and Projects? My tree looks like this: Core -Home -Documents -Media -Templates But what I seem to need is more like: Core -Profile -Calendar -etc -Documents -Media The problem at its root is in how I display these menus on the front end template? I can simply loop through the children of Core to make the main menu, but I can't do that if I DON'T use the Home page. I hope this makes sense. If I loop through children of Core, my main menu would show BOTH my top-level menus (Documents, Media etc) but ALSO the Profile and Calendar which are supposed to be sub-menus of Home, not top-level menus. That doesn't work. I have to instead do like my first example, which is then a piece of cake. Loop through children of Core and that creates the main menu. However, THAT is where I have the problem of two different "home pages", one at example.com (which shows Core), and one at example.com/home/ (which shows Core->Home) My first solution to this was to exclude Home from the loop and instead hard-code the Home link into the main menu to go to example.com, essentially trying to pretend that there is no such thing as example.com/home/. That isn't working so well. I tried to eliminate Home and just use Core directly for my home page content, that isn't proving to be very good either because of the page heirarchy structure and where to put my Home page sub-menus and loop through them. In order for Profile and Calendar and such to be children of "Home", I actually need there to be a "Home" in the first place! Here is what I'm ideally looking for: Core ( essentially non-existant as far as front-end goes ) -Home ( accessible as example.com, don't necessarily need or want example.com/home/ ) --Profile ( child of Home, making it easy to loop through for children or siblings ) --Calendar ( these could literally be under example.com/calendar, as I don't want /home/ ) --Projects -Documents ( child of Core, thus part of main menu when looping children of Core ) -Media -Templates Logically, I want to loop children of Core and make a main menu which includes a "Home" item that takes me to example.com. And when a user clicks a main menu item, that main menu will have its own landing page and content, but ALSO show the sub-menu, i.e. children of itself. On top of that, when a sub-menu is chosen, that page will load, and continue to show the top-level and sub-menus. There should be visual clues so people know what page they are in. For example if they click Media then that menu item will get a class=active, and if they click Media->Logos, then BOTH the main menu Media as well as the sub-menu Logos, will have a class=active. I had trouble with this because when you click a MAIN menu, I show CHILDREN of $page which creates a sub-menu (works great), but when you click the sub-menu item, children of $page shows nothing. So I have to somehow toggle in the template file whether to show children, or to show siblings for the sub-menu, or perhaps children of $page->parent for example. It's kind of confusing I think. If any of that nonsense made any sense at all, can you help me sort out my logic in how to organize this simple structure? Much appreciated! Link to comment Share on other sites More sharing options...
pwired Posted March 8, 2014 Share Posted March 8, 2014 Not sure what you are after but maybe this might help:http://processwire.com/talk/topic/2300-structure-best-practice-grouping-in-admin/http://processwire.com/talk/topic/740-a-different-way-of-using-templates-delegate-approach/But looks like you over-complicate your approach.ProcessWire uses a hierarchal structure for pages you setup in the backend.In your templates you can call whatever page you want.http://processwire.com/api/templates/section: finding and loading other pages from your template filehttp://en.wikipedia.org/wiki/ProcessWireQuote:ProcessWire is built around a page content tree (as opposed to a bucket system). The URL or path of each page is always reflective of its place in the hierarchy. One uses this same path to reference the page in the API. As a result, this connection of the path to the internal tree hierarchy is important to the architecture of ProcessWire.Beyond the parent-child relationship implied by a content tree, ProcessWire supports relational one-to-one and one-to-many references between pages in the tree. 3 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now