wilsea

Thanks for the comments kongongo. Joss's post on pages is a gem. I did a little bit of editing to try to make it clearer that it's the template files that control the display and not the templates. Thanks for pointing out that the template files didn't have to have the same name as the templates - bit of an aha moment there. One template for the viewed page, another for the page to be printed. Back to the API...$pages have a template property, and templates have a filename property (and lots of other properties too). That thread about advanced use of template starts to make more sense now. I recall reading in a post somewhere that PW is addictive. They were right. I'm hooked.

I'm new to PW as well, but here goes.... pages This is how I understand it at the moment. The biggest conceptual shift is moving away from the idea that pages are web pages. In PW they are more than that. Pages hold data, so think of pages as more like records in a database. Exactly what data the page has depends on the template the page is using. When you create a new page, the first thing you do is choose a template for the page. templates. (1) Templates keeps track of what data items will be stored with each page eg name, position, phone etc. Each template uses one or more fields, and you decide which fields when you create the template. (These fields can be changed later on, if you wish, but obviously deleting a field will also lose the data associated with that field ). The data is collected when you fill in a form on the admin panel for each staff member, or if you already have a lot of data you can import the data as a csv file using the Import Pages from CSV module, You can have as many templates as you like, and fields can be re-used in multiple templates. (2) the template usually has a php file of the same name in site/templates that manages how the data is displayed. The template php file is where the code goes to produce a simple vanilla display of data, or can get as fancy as you like with tables, tabs, and whatever collection of whistles and bells you like. Each template has access to the $page variable that comes with PW, which can be used to refer to each item of data (ie the fields in the template) on your page, using syntax $page->myvariable to refer to the data in the field. eg If the page had a field first_name, then echo $page_>first_name would print the first name of the person associated with the page. Ryan explains it really well at http://processwire.com/talk/topic/43-template-tutorial/ (3) templates are created from admin>setup>templates>new template. This is where the fields are connected to the template (and to pages using the template). The php file manages the display of the page. It doesn't seem to matter whether you create the php file and import it into templates first, of whether you create a template first without a matching file and ad the file later. To display a page for Fred Nurk, you would have a page using a template with fields for name, phone and whatever else you want to record, and a template php file, with the same name as the template. If your template was called staff, you would also have a file staff.php, in site/templates. If the page for Fred was under a subdirectory called employees, and the title field was used for his name, then the page could be viewed at yoursite/employees/fred-nurk/ fields fields are containers for information. Fields need to exist before they can be added to a template. Fields are created from admin>setup>fields.new field. Each template has a mandatory title field, which is used to when a page is displayed in the pages directory tree. It's also usually used to build the url address that will be used to view the page. Getting information in a page from other pages You can get information into a currently displayed page from another PW page, by using the $pages variable and any selector that seems appropriate. There a number of different selectors that let you locate a particular page or group of pages by a wide range of criteria. The API section on Selectors is a must read and reread.(It's a lengthy page full of essential information and I found it took a while to take it all in - it might be worth printing it out ) The selectors take all the pain out of querying the database .For example, selectors might be used to set up a loop through each of the staff member pages (remember pages are like database records) and generate a list of phone numbers on one page. If you're keeping things like skills on separate pages, then you can use a selector to get information about the skill, and add that to your page on Fred Nurk. In your template php file you would use a selector to locate a page or group of pages, eg $myfoundpage=$pages->get(some selection criteria) or $myPagesArray = $pages->find (some selection criteria), and then you have access to all the fields associated with $myfoundpage through its template. If the template for $myfoundpage has a field for pet_name, then $myfoundpage->pet_name will give you the pet's name. It you want to get really fancy, you can display entire multiple pages inside one master page, using the render method of a page (it comes with that $page that is built into eachPW page.) echo $pageA->render(); echo $pageB->render; echo $pageC->render; would display the contents of all three PW pages on the one browser page. Or you might set up a master/child type of page, where the contents of the bottom part of the page are changed through an ajax call depending on what actions are taken at the top of the page. You'll probably get the idea pretty quickly by getting in and having a go. I'd suggest using a really simple template and going through Ryan's mini tutorial on templates at the end of this post The tutorials section of the forum is a pretty good place to start as well. There's also the wiki

Thanks for your interest Ryan. The problem is at my end, as anticipated. It just took me hours and hours to realize that although all the codes were 9 nine letters, some of them should have been 8 letters, and the 8 letter ones are padded with a space at the front. Aaaarrrgggghhhhh. How could I be so blind. Please accept my apologies for wasting people's time. I'm uber impressed with PW - a joy to use and awesome support. I'm basically a retired hobbyist relying heavily on google and StackOverflow for programming knowledge. I started out with Wordpress , found that it was a pain t to customise, so was Drupal, CodeIgniter didn't light my fire, and Laravel assumed far more coding knowledge than I have. But for me PW ticks all the boxes - easy to learn, easy to use, helps you learn PHP and build a site that does what you want it to. Thankyou for making this product open-source. It's a game changer. I started with a brand new database

As a newbie, this post is gold! Can't believe I didn't see it earlier despite numerous checks of the FAQ forum. I only noticed it after doing an advanced search for siste:processwire tutorial updated in the last month Thanks so much for such an organised collection of information.. Is it a candidate for a sticky?

Just found the Selector Test module, and I get exactly the same results in it as I do with the Batcher module.

Thanks for the continued interest. I'd love to track down what is causing it if possible, but I fear it may be operator error and I'm reluctant to waste people's time I've been really impressed so far that PW seems to take everything weird thing I try to do in its stride. The initial slow response (by PW forum standards) had me thinking that I was probably the problem, so I started again with a completely fresh database and completely fresh installation of PW. Even the data was freshly exported from the database. I reimported the data, and the problem was still there. The pages were generated using the ImportPagesFromCSV module. The data in the PW field_code table looks fine - all 9 characters. I have another template which uses the same acara_code - it checks out OK in my original data, but I'm not sure where I'd find it inside PW - it's a property of my Details template, which uses an autogenerated id from my original database table as the title field. It's highly unlikey that it is any different , since the database data was generated using a program which used the same variable for each database table. Both tables use a TINYTEXT field for the acara_code column in the source database. Codes 1486 through to 1583 all work, but 1584 to 2430 don't work. (how do people do those neat thumbnails?) The breakpoint for the codes that work and those that don't are related to the top level table of a straight forward series of one to many tables. My heirachy is Subject > Strand >Substrand >Topics > Details. Strand (strand_id,strand_subject,strand_name) Substrand (substrand_id,substrand_name, strand_id) Topics (code_id,substrand_id,code,code-detail,level) Details (detail_id,code,topic-detail) The six Subject pages were created from the admin panel using Batcher- all children of a hidden Subjects page. The other pages are all created using the ImportPagesFromCSV module. The code is used to link the Code and Details tables - and that's the only time it is used. Codes 1486 through to 1583 all work, but 1584 to 2430 don't work. However the searches work fine for the codes with the first great grandparent in the subject table. All codes that can be traced back to any other great grandparent Subject (there are 5 in total) don't work. I don't see any reason why that relationship should cause a problem - maybe it's a red herring co-incidence. However it's also the only thing I can find about the codes that work and the ones that don't. It might well be that I'm doing something wrong, but I've run out of ideas for what else I can do of check to find out what's going on. Over to the detective squad!

Hi Nik Thanks so much. I didn't even think to try the % contains operator. It made all the difference - search works as expect with the %. I tried the SQL LENGTH query (haven't struck that before). SELECT LENGTH(acara_code), acara_code FROM acara_topics showed they are all nine characters Odd. Still, it works now for whatever reason Simple instant fix! Thanks again!

Not sure why sometimes I get results with a selector, and sometimes I don't,. I have 180 pages all with the same template with title , description(each is unique) and code (one of 71 different 6 letter string) fields, and all nested under the same page. Each page displays as expected when viewed directly via it's template or in edit mode. The title is a number string from 1 to 180 (the unique auto-id's from the original source table). No other templates have a number as the title field. No other pages use the same template. $pages->find("template=acara_elab") works as expected - 180 pages are returned, and I can display the description and code fields of each returned page. $pages->find(template=acara_elab, code="xyz") works as expected for the pages (1-98), but fails to find any record 100 and beyond, including searches using the Batcher module. There are 71 different codes. The first 98 records use the first 33 codes (all codes are 9 letter strings). The non_displaying codes (in Batcher and from templates other than the original template) all use the last 38 codes. $pages->find(code="xyz") works if "xyz" is any of the first 33 codes, but fails to return results if any of the last 38 codes are used. Does anyone have any suggestions how to find out what is causing this behaviour?

Thanks so much for all the suggestions people. I ended up opting for pages built from four tables, and that seems to everything I want and more. For the benefit of any future readers..... While it's probably self-evident, a separate template for each table made the whole process easier to manage.Tables imported like a dream with the import Pages from CSV module. What was even dreamier was correcting a few mistakes or three (having too much fun with PW to catch up on some sleep) with the ability to do bulk trash/change templates operations with the Batcher module. I found out the comma delimiter is a bad idea if your field already has commas in it (duh). Delete mangled pages, reimport as tab delimited, problem solved. Linking the tables/pages up inside PW was a joy instead of a nightmare. There's probably better/other ways, but I just coded the templates to provide the functionality (mostly navigation and display) that I needed. I'm wrapt and can't wait to push the envelope further. Who'd of thought Christmas would come round again so quickly.

Thanks Pete, delighted to post the database structure. Basically it's a simple 5 level heirachy, one to many down through each level. Level 1 - Subject - 6 records (name only) Level 2 - Sub-subject - 18 records (name only) Level 3 - strand - 40 records (name only)(3rd letter of topic_code) Level 4 - topic - 1000 records (4 fields + id) (4th and 5th letters of topic_code) Level 5 - details - 3000 records (2 fields + id) Subject and sub_subject probably don't need to be in the database, as they are pretty small and consist of only a name field. Fortunately the topics table has a topic_code field which can be parsed to get information about the subject and sub_subject. The topic_code is a unique field about 98% of the time. topic_code plus topic_level is always unique. Id fields at the top level of each table are auto-increment numbers. Likely searches and groupings will be on subject, sub_subject, strand and topic_level (there are only 10 topic_levels). Page fields for each of these.will be handy for the rest of the site. It's highly unlikely that the details table will ever need to be searched directly, but the topics table will often have records retrieved by the topic_code. I rather like the idea of a custom table field like the FiletypeEvents for the topics table, but I'm not sure how to go about setting up the relationship between the topics table and the details table. I haven't figured out what is doing the actual save in the Fieldtype Events. table. It seems to be a submit post to itself, but I can't find any actual save type code any where, and I'm not sure where to look. Thanks for following this post. Great forum!

Thanks SteveB, Adrian. Looks like it might be time to tackle the modules tutorial.

Thankyou both for the blazingly fast replies. A big help in clarifying my thinking. I hadn't thought about URL's, obviously a big point in favour of pages, which got me thinking about url's verus ajax, and bookmarking/back button issues. Those event field types look really interesting. I'm really intrigued by how much can be done with a small amount of code in a module! Heady stuff if I can only get my head around it all. I see a table with the data is added to the database, with multiple columns instead of the usual two column field tables. I guess once the table is created I could add records to it using regular php. I'm also guessing that I could customise it by changing the fields in the __construct() array of Event.php, (Sorry if I'm stating the obvious - I'm still wobbling around on trainer wheels. Just checking to see I'm on the right path). If I was using a regular mySQL database there would be about 5 or 6 tables, most of them very small. The biggest one will have about 2000 records. The data is static - no CRUD at all once it's in place, but other pages on the site will reference to it, and the data will need to be easily browsed and displayed by various search configurations. Still mulling over the options over the best way to go. Thanks very much for the suggestions. They've given me a lot to think about.

Still a newbie to both processwire and php.......just checking that my thinking is long the right track I want to set up a heirachical site with the following structure Categories (6) > Subcategories (3 per parent) > Sub-subcategories(2-10 per parent) >Items (1-10 per parent). References to the various levels of the heirachy will need to be available to other pages on the site. I get the idea of doing it in pages with relational page fields, nicely explained in Tutorial: Approaches to categorising site content . It looks as though it is also possible to add tables directly to the database (or even another database). It's delightfully easy to use a template to display the data on each page any way you want. It seems there are two ways to access the data. With the data as pages, I could use a selector to query the database.e.g $items = $pages->find("template=mytemplate"); //or any other selector With custom database tables, I could query the database directly e.g. $result = $this->db->query("SELECT id, name, title, url FROM yourtablename WHERE id=$id"); Is there anything I should know about the pro's and con's of either method before I build the site. The data already exists, but I'll be scraping a website to get it, so it will be added to my site under program control. I'm not sure whether my program should create processwire pages, or just create some database tables. Actually now that I think about it, both are possible, table first, then pages created from a table. I'd really appreciate any comments before I unknowingly head off down the wrong track.

Thanks a million apeisa.

Is there any simple way in ProcessWire to have the contents of one input field vary depending on the choice made in the first input field. For example, if the user selected farm in field A, then field B choices would be horses, cows and sheep, but if the user selected fruit in field A, then field B choices would be apples, oranges and pears. I know it could be done with javascript and ajax, but I'm wondering if there's another other way, maybe some code in one of the form fields. The video at http://processwire.com/api/selectors/inputfield-dependencies/#examples looks really nice, but I can't find the show-if and require-if options shown in the video in my recently downloaded copy. I guess those options are in the latest development version, but I always seem to end up with the latest stable version. After tearing my hair out with WordPress, Drupal, I'm finding ProcessWire such a joy to use that I'm getting more and more ambitious in what I want to do.(and in a fraction of the time ).

Thanks Adrian, While fiddling around with the config file I noticed that the templates did not match up with what I thought was a clean copy of ProcessWire. Looks like I ran the installation and ended up with a database that didn't match the templates I had. I'm not sure why that would be a problem, I would expect that would just sit in templates directory ready to be imported, but I decided to play safe and make sure there was nothing else unexpected wrong by reinstalling. Problem solved. Thanks for the help - now I know a bit more about turning on the debug from config file. Looks like the problem was all my doing - oops.

Thanks Adrian, Not sure where I'd find the config settings on the hosted server. Server uses cPanel. Do I change something on .htacess in the processwire directory? Please excuse my ignorance.

Checking further on the above problem....I can view and add fields in Admin>Setup, but I can't edit the fields. I just a similar blank screen to the above screen shot with a heading Edit Field: somefieldname, and a drop down select box with the pages using the Field. Maybe that helps isolate the problem. Anyone? (I've been spoiled by the outstandlingly quick responses I've previously had on this forum, and really excited about getting a live version of ProcessWire up and running).

I've played with ProcessWire on localhost, and now I'm trying to get it running on a live server. It installed OK, I can log in, add pages and templates, and add new fields, but I can't view template fields, even for basic-page. All I get is an empty space between the Edit Template:basic-page and the Save button. See screnshot I checked the core....there are three files Template, TemplateFile and Templates. that all look OK. Other than that guess I haven't a clue what to look for. (I'm hoping that ProcessWire will help me develop some php skills). Does anyone have any ideas what the problem might be?

Thanks folks - disabling xdebug as suggested in the link solved the problem. My disabling was pretty crude - I remmed out the line in php.ini where xdebug was installed by putting an aposthrophe in front of it. ie; ;zend_extension = "c:/wamp/bin/php/php5.4.3/zend_ext/php_xdebug-2.2.0-5.4-vc9.dll" Not sure what I'll do now when i want to do some step through debugging though.

I'm trying to use a repeater, following the guidelines at http://processwire.com/api/fieldtypes/repeaters/. I installed the repeated module, created a repeater field, add three text fields to it, and then added the newly created repeater field to a template. When I try to create a page based on the template containing the repeater field, I get the following error message. Error: Maximum function nesting level of '100' reached, aborting! (line 114 of C:\wamp\www\process_edu\wire\core\Data.php) What am I doing wrong?

Love the response time of this forum. I need to spend more time digesting that link (and the associated links). I'm not sure that it's quite what I'm looking for. I don't want to autogenerate names, I want to be able to supply a meaningful name when I upload the file, so that later I can then display links to the file using the meaningful name. So far the more I test out ProcessWire the more I like it. Different...but very nice.

Sweet! That's exactly what I mean. I'll be happy to help as soon as I know my way around ProcessWire a little better.

Is there any way to tweak the file field or to set up a page so that if more than one file is associated with a page, a user-friendly name for each uploaded file can be added as well as a description? If the file has some horrific and meaningless filename like rfu_o3.docx, I'd like to refer to it using a syntax something like my_file_field_name->name, where name for file rfu_o3.docx might be "Dog's breakfast". Repeater came to mind but doesn't seem to be quite right....(I'm still fuzzy about repeaters). Maybe something to do with hooks ? Or maybe there's a really easy way that I'm missing. Can anyone offer a little enlightenment?

Thanks for those replies. Plenty of reading once you know where to look. Really great to have such an active forum. My earlier comment was referring specifically to the cheatsheet - The onclick description of each method and field is great, but difficult for newbies like me to figure out how to actually include in code eg $page->find("selector")....A quick example of when you would use this with some actual code would be great. I guess I'm a little spoiled by jQuery, where each item in the documentation has an example of useage, and since ProcessWire is inspired by jQuery...... What about renaming the api heading to Documentation or User Guide (or similar), which includes a list of tutorials (as in the forum). I suspect a lot of potential users might not be determined enough to check out api and forum to find this information.