kongondo

PAGES: Yes, everything is a page. There's a topic that explains this approach but I can't find it atm. A page is an abstract term; it doesn't always map 1:1 with a web (or book) page. Being abstract, it can be used for various tasks including storing data, displaying content, etc. Have a read here too. CRUD: There's Batcher (check in modules) and this current discussion GLOBAL HEADER/FOOTER: There are various approaches. One is create pages to hold the information (respectively) and call those pages in your templates. See also the PW default install template files and this topic plus this in the docs. FIELDS: Templates help group your fields together. This is a big topic. Have a read here. Note that fields are reusable and are all custom; there is no required field in ProcessWire (although each page must have a name but that is not a field you create; it comes with the system). Templates can share template files, can have their own template files or can have NO template files Confused? It all depends on what you want to achieve. See this topic and this in the docs. Bottom line; if you want a page's content to be visible in the front-end, that page must either use a template that has a template file or that page must have its content pulled into and displayed by another template file. Gotta go. Meanwhile, you could search the forums for more info as others chip in. You might want to search this forums using Google; it is better than the forum board's search

The folders contain images uploaded on a page. The folder names are the IDs of the pages. See the following topic for a discussion about this issue: http://processwire.com/talk/topic/992-problem-with-assetsfiles-folder/ And an empty folder cleaner http://processwire.com/talk/topic/1585-module-clean-empty-directories-from-siteassetsfiles/ http://modules.processwire.com/modules/page-clean-empty-dirs/

<offtopic>@Zahari, no need to apologise for having a different opinion . We can't all think the same and nobody here expects us too </offtopic>

RE all pages in the tree looking the same, this module Template Decorator might interest you: http://modules.processwire.com/modules/template-decorator/

@Wanze, Thanks. Ye, HoT it is really awesome . Yes, I am already working on a module for Handsontable but it is at a very early stage. In fact, I am basing my code on yours (Batcher). Btw, your code has taught me a lot, thanks - well-written and commented and just makes me understand PW even better. Hmm, just wondering whether it makes sense to have two separate modules or one (Batcher) to rule them all! I have been planning to have my module handle both PW and external tables (data handling on demand basically), although that could add to the complexity. Like I said in the first post, I would need help in coding the module, especially settings/configuration to allow the user to enter options offered by HoT. It's also a good learning experience for me to better understand PW. I suggest we mull this over a little and hear other thoughts as well (i.e. one module or two). ATM, I don't see any reason why these should not be combined but I would (if possible) want the ability to edit external tables. What is your opinion about this (external tables)? So, in a nutshell, yes, I'd love to collaborate with you on this but let's make a final decision once we hear what a few others have to say...just to be sure we are considering all angles

@All thanks! @Pete, Ye, Marcin Warpechowski has done some amazing work with HoT.

Having looked at several PW Admin themes, I can safely say creating a PW admin is quite "easy". It is just a page after all. I have been toying with some admin theme ideas lately (too many ideas, so little time!) but haven't finished (er, haven't started) on any of them. Down the pipeline (very long pipeline) I will do a tut on how to port different admin themes to PW. It is just a matter of outputting the content you want in the "section" you want... I'm too lazy to search atm but yeah, this topic has been discussed before. I think PW aims to remain simple to use. And because it is simple to use and build things with, stuff like admin themes can easily be built/customised by the user rather than provided in the core. Just my 2 pence

MODX did teach me a lot too. With PW I have learnt even more and am steadily moving from designer to semi-developer if there's such a thing PW has encouraged (not forced) me to move in this direction and the journey so far has been thoroughly enjoyable. It's so refreshing to type code, throw in some logic here and there and to see the results displayed! Anyway, I digress. You've made the right choice to start using PW. Enjoy!

I was just about to ask you about that. AFAIK, in PW parent IS NOT same as grandparent. For grandparent you can use has_parent property (http://processwire.com/api/selectors/). Currently, you can only specify one value for each declaration of has_parent in your selector, so you can do has_parent=5, has_parent=15 BUT CANNOT do has_parent=1|87|90. I think there is another approach to querying grandparent ancestry relationships as well; I can't recall it atm. Exclude a whole tree or a whole branch? Yes, you can do both...using ancestry and/or template association...

I'm not suggesting that it won't work in current stable release (2.3); I just haven't tested in that environment (yet). Edit: Tested with current stable (non-dev) version (2.3). It works as expected; parent!=1020 excludes children of 1020 from Select selection in Page Reference Field (tested with single Page Ref Field) when logged in as non superuser. Meaning...that was not your issue...

Thanks bcartier. Yes, I plan to have a filter (if this goes to production ) The filter would be trivial to implement I think - if not, I'll just pinch it off Wanze's Batcher

Allan, If home page had no children your website would have only 1 page; home In PW, all pages are children of Home. So, home has children. This is even evident when looking at the site map page..."about", "site map" and "templates" are all children of home. I can see the same thing in your test page meaning you haven't changed much. Even if you had, yes, all those other pages (if you had them) would still be children of home Remember, the renderBodyNav($page->children) code is specific to the page being viewed. Page always refers to the current page. So: When viewing home page, you see links to its 3 children (about, site map and templates) + the "orbit images", i.e., renderOrbit($page->images. When viewing about page on your site, you see links to its 2 children (Child page example 1 and Child page example 2) and 3 children (in the PW default install with Foundation example - Child page example 1, Child page example 2 and Typography Tests) As for HTML code in the template files (/site/templates/), these are mostly in _main.php, I believe. Create a local (WAMP/XAMPP, etc) test install of PW using Foundation profile (although I'd suggest you start with the default profile). In /site/config.php, turn debug on (true). Then, I suggest to go through each and every template file used (minus admin.php). There's only 7 of them. That way, you'll see and study what's going on behind the scenes, follow the code to see where the rabbit-hole leads. Test things. What function calls what? What file is included? Comment and uncomment the code to see what breaks and happens, even deliberately throw in silly undefined variables in the works. What breaks? What error does PW through? Of course this will be a test environment and you can always undo. Write notes along the way (even better as your personal comments within the code itself). Additionally, you can use the trick I showed you above. Look at the HTML source and use things like "id=xyz" and class="abc" as terms to search/grep through the template files in /site/templates to find out where the HTML is coming from.

See my edit above. In my case (am on dev branch) it RESPECTS parent is not (parent!=123)

Regarding selectors, if you think about it, superuser means just that...there are no no-go areas for them . But, like I said, I would wish for admin pages not to be incuded at all (irrespective of selector) in the Page Reference Fields. I can't think of a scenario where even a supersuser, in a Page Ref Field, would want to select pages that should not be viewable at the front (modules, trash, etc.). Let's hear what Ryan has to say Hmmm. That works OK on my end. When logged in as non-admin, I am not able to select children of parent = 1057 in my Page Ref Field...

Hmmm. I have tested this and I think you might have found a bug ( NOT A BUG; SEE BELOW)...The thing is using the ! declaration results in crazy results. E.g. template!=admin, like you've said, returns admin, trash etc. I am testing on dev branch (from a couple of days back). I'll test further before reporting as a bug... Edit: Tested further outputting content in the front end with a find call using a selector "template!=basic-page); If you are logged in as superuser, you will see all pages including trash, roles ,etc (since you are superuser). If not logged in (or logged in as a user with less privileges) you don't get to see those privileged pages (admin, etc.)...I'm guessing that's what's happening in the above case since Alkahest (I suppose) tried above when logged in as superuser. As for parent!=1057, am still investigating that... Edit 2: parent!=1057 (for example), results in the same as above...modules, access pages, can be viewed... I suppose it makes sense though, because the find is specific? Looks weird though in the Page Reference Field even for superusers Edit 3 I don't think this is a bug. @Alkahest, If you use the "Custom Selector" approach, your client will not able to see those admin and setup pages etc in the Page Reference Field drop down since they are not superusers. Try and log in as "client" and you'll see what I mean

There are some videos but nothing about forum modules I am afraid. About a foreign key and its use, I'll let the lead developers answer that. By post you refer to "forum" posts are you referring to the "Discussion" module I referenced above? I am not away of that but please feel free to ask in the support board of that module.

Did you give "client" access in the templates themselves (see my previous posts) I am not following. What do you mean you deselected "Parent" and "Template"? I get you, my bad So they shouldn't be able to pick "A custom menu", "Arbitrary Link", etc? In you setup, which pages should they be able to pick? I can't tell from your post. You must be doing something wrong somewhere but hard to tell at the moment..

Allan, When on the homepage, you are talking about the highlighted content as in the screenshot below, right? If you look at the HTML source of that page you see this code: <ul class="body-nav side-nav"> <li class="divider"></li> <li><a href="/foundation/about/">About</a> <span class="summary">This is a placeholder page with two child pages to serve as an example. </span> </li> <li class="divider"></li> <li><a href="/foundation/templates/">Templates</a> <span class="summary">More about the templates included in this basic site profile. </span> </li> <li class="divider"></li> <li><a href="/foundation/site-map/">Site Map</a> <span class="summary">View this template's source for a demonstration of how to create a basic site map. </span> </li> </ul> Notice the class in the <ul>? It is "body-nav side-nav". If you look at _nav.php, line #100 you see this code: 'class' => 'body-nav side-nav', which is part of the function renderBodyNav. That tells me that function is responsible for the <ul>......</ul> code above. So, we search for instances of that function in our template files. This will lead to 3 places (including search.php) but the ones we are interested are on home.php (used by "home" page) and basic-page.php (used by "about" page and others I presume). What the code does is this: In the case of home.php, it looks for the children of "home" and creates a list with links to those pages (and appends them to $body). I haven't thoroughly looked at the code but I believe there would be a limit clause somewhere so you do not get all the children of the home page (they could be many!) $body .= renderOrbit($page->images) . renderBodyNav($page->children);//home.php Change that code to this $body .= renderOrbit($page->images);//home.php We have now removed the call to renderBodyNav. I understand, the name can be misleading, but look at this way...the list is just a navigation; a navigation to child pages. In the case of basic-page.php, the code first checks if the page being viewed (in this case pages using basic-page.php as their template file) has children (the $page->numChildren(true)). If it does output the child pages as a list (appending them to $body). If it doesn't, do nothing... If you don't want the list of child pages to appear in pages using basic-page.php (like "about" page, I presume), then change: if($page->numChildren(true)) $body .= renderBodyNav($page->children); //basic-page.php to this; we just comment it out. //if($page->numChildren(true)) $body .= renderBodyNav($page->children); //basic-page.php Test this and see how it works. I haven't studied the code in-depth so check if there are consequences in output that comes after that list... I suggest that you read up on PW, specifically these documents: http://processwire.com/api/selectors/ http://processwire.com/api/variables/page/ http://processwire.com/api/variables/pages/ Also, check out the PW wiki and go through the tutorials. This way, your experience with PW will be much richer and you will be amazed at how quickly you can build things with the system. I am not suggesting that you should not ask questions. I am saying if you understand the system, you will have much more fun and satisfaction when you look back at what you've accomplished and there will be less hair pulling (your hair, not mine, hehe)

Hi Allan, In future, please post questions related to the Foundation Profile in its forum support thread here: http://processwire.com/talk/topic/4014-zurb-foundation-4-site-profile/ Make's it easier for the developer to pick them up plus keeps everything related together Qn#2: That seems to be coming from these code in basic-page.php and home.php templates files which are calling the function renderBodyNav (see this) in _nav.php $body .= renderOrbit($page->images) . renderBodyNav($page->children);//home.php if($page->numChildren(true)) $body .= renderBodyNav($page->children); //basic-page.php How comfortable are you with PW and PHP? I'm just wondering if the code in this profile may be a bit advanced for you at the moment?

Hi dhruba, Welcome to PW and the forums! There has been talk about a forum module for PW but nothing has materialised so far. There's these topics that could be of interest: http://processwire.com/talk/topic/3536-forum-integration-module/ http://processwire.com/talk/topic/572-release-discussions/ Could be relevant: http://modules.processwire.com/modules/fieldtype-comments/ http://modules.processwire.com/modules/process-latest-comments/

Jasper I think what's being said is that the code has: status=published which is not valid. What is valid is status=unpublished. So, I suppose, if you want to check if published, you negate the status, i.e. status!=unpublished. I'm probably misunderstanding what you are getting at

@Pete...something like this? http://processwire.com/talk/topic/4147-excel-like-crud-in-pw-using-handsontable/

In some previous posts, I demonstrated a simple proof-of-concept CRUD “application” for PW using jTable. I really wanted to use DataTables since it is older, wiser and with a huge fan base. One thing I wanted was for the CRUD system to be as simple as possible and possibly be Excel-like (more below). With DataTables plugins, you can perform stuff like inline-editing and Auto-fill. The latter works just like in Excel and allows you to quickly populate cells (quick copy). But that’s as far as it goes. Google led me to other Table management systems. Some of the front runners include jqGrid and SlickGrid. SlickGrid is nice and using virtual rendering can display millions of rows with ease. Its support for displaying data delivered on demand (Ajax/server) is minimal; it requires you to download all your data before it starts manipulating it. Someone has created an Excel-like extension for it allowing copy-pasting between SlickGrid and Excel. Awesome! But, it still didn't rock my boat completely, especially the Ajax content issue. Then I stumbled upon Handsontable, a new kid on the block that describes itself as “a minimalistic Excel-like data grid editor for HTML, JavaScript & jQuery”. Though relatively new, it is as Excel-like as you can get. You can copy-paste from/to Excel [single to multiple cells and multiple to multiple cells], use the usual shortcuts (Ctrl-A, Ctrl-X, Ctrl-C, Ctrl-V, Ctrl-Y, Ctrl-Z - i.e., undo/redo, etc., and tab navigation, etc.), use Auto-fill (vertically and horizontally), freeze cells/columns, make cells/columns read only, Right-click context menus, insert/delete rows and columns, perform inline-editing, etc. Double awesome! Handsontable (HoT) is minimalistic but comes with a rich API. However, most of the implementation is down to you (sounds familiar?). It will render the Table and provide you with Methods/Events/Options to manipulate it. You just have to provide the data as an Array or JSON defining your columns and containing your data. Soma has a DataTable module that is currently read only; you cannot edit the displayed data directly in the table. It is also in lazy development . So, I started toying with the idea of using HoT as an Excel-like CRUD system (module) for PW. I wanted something that could quickly and easily do mass editing (Batcher-like). Imagine quickly creating basic pages/records by copy-pasting from Excel. Or quickly changing records by dragging (Auto-fill) or pasting new values over old ones. Well, the result can be seen in the screencast below. I’d like to hear your thoughts whether this is something that I should consider developing into a module; something that could be used by Superusers. Depending on implementation, it could be used by other users as well. All HoT needs is data. What you do with that data is up to you (the developer) and your code! This can be very dangerous if not implemented correctly, of course! You could easily delete important records! However, HoT does not touch your database! Deletions, insertions, etc., will not alter your database unless you specifically write the PHP code to do that. All it does is send data to the server via a method your specify (post, get, Ajax, etc.), and even that is your implementation. You do not need to implement deletions or additions. You can use it for updating content only or as read only, but where’s the fun in that ? In the screencast , apart from the table itself, all the other implementations are custom - the buttons, selects, auto-save (can be tricky? can DDOS your server?). The current implementation is not perfect; it is a demo after all. Certain stuff would need to be implemented differently . I didn't want to spend too much time on something that would not be useful in the end. All CRUD operations are via PW API and/or vanilla PHP. Deleted pages are Trashed and not permanently deleted. If there is interest for a module of this kind, I would request all the help I can get to develop it please. I would put it up on Github of course. In the demo, this is running off Diogo’s ACP module. Let me hear your thoughts please. Should a module like this see the light of day? Thanks Wasn't sure in which forum to post this...

Brilliant! Glad you got it sorted.. Useful links for upgrade: http://processwire.com/talk/topic/530-profile-export-module-also-upgrade-pw-20-to-21/ http://processwire.com/talk/topic/853-processwire-22-soft-launch/ https://github.com/ryancramerdesign/ProcessWire Welcome to PW and the forums..

Hi Debbylevinson, A quick one. The most important thing to do before you try to recover the site is to backup the /site/ folder and the database if you haven't done that already. Make sure you do that before taking any action. I'm pressed for time ATM but you have several alternatives...Before that... check in /wire/config.php There you will see the ID of the superuser and the role ID of the superuser. In PW 2.3 these are 41 and 38 respectively. You can also see this in phMyAdmin if you look under field_roles and pages. So, under the table "pages", find the name of the page with ID 41 (see "name" column). If you are still unsure about what to do, I'd be happy to chat via PM.