kongondo

These three are a must read in order to use PW $page: http://processwire.com/api/variables/page/ $pages: http://processwire.com/api/variables/pages/ Selectors: http://processwire.com/api/selectors/ Btw (sorry to be pedantic!) ProcessWire really does not have a syntax (in the sense of MODx syntax, for example). It's all PHP

Wanze. Thanks for sharing this (and to Reno for asking the question!)! Everyday I continue to be awestruck by the simplicity, cleverness and power of ProcessWire. With about 11 easy-to-follow lines of code, without touching the core, without bashing the system into submission by throwing all sorts of plugins at it and without compromising security and future updates, this opens up a whole new world of possibilities all at the drop of a hat.....Fantastic!

Your pagination code? Could be a start or limit issue. Paste you whole code to help us debug....

Requirements: * jQuery script like Fancybox or Colorbox, etc PW won't get into your way. It doesn't care what you use. You could use Mootools if you wanted to (does that still exist, btw?). So, yes, use whatever you wish. But you need to include the script yourself * Image file uploader from the PW admin system (front end) would be nice, but I am ok with uploading the images to the server via FTP if I have to. You can do both. For frontend, there's loads of examples on the forums about (see also Soma's Gists..). With frontend, the more important thing is security.... * Must have control over the generated thumbnail size. This is critical. The full-size images will be set by hand using Photoshop. Yep. Right out of the box. See here... * Access to the grid presentation of gallery thumbnails via a CSS file. Like I have said (previously)...PW doesn't generate or output markup. So, you can output whatever you wish with whatever CSS you wish. PW doesn't know or care so to speak * Pagination: ability to have a single page presenting one gallery of images or a page presenting multiple galleries on a single page. Pagination...right out the box...See here * Fast load times. Excuse me? Oh, OK, what Macrura said * Ability to include image title names and captions OR the ability to not include titles and captions. See here. echo $page->image->url; echo $page->image->description, etc, etc for what you want to show. If you don't what to show them, don't echo them. There are other techniques (yes, the dreaded PHP!) - e.g. echo description only when it is not empty...We can show you how to do that....Also, there's no image title per se, but there's ways round that... Note: In the above "image" examples, this is just echoing out a custom image field called image. There is no field in ProcessWire called image (or anything else actually). Like any other field, you give your image field whatever name you wish (within acceptable fields' naming conventions, of course). So, this could well have been echo $page->photo, etc. Final thing, you can have either a single image field or a multiple images field. For the latter, that's an array...As with all arrays..you need to foreach (loop) through it to output stuff. There are other stuff like echo $page->photo->first() but that's for later

Max, you raise some good points (that have actually been raised before ). I'll comment on two of them: And you are absolutely right. Remember though that PW is still a young system (in relation to it being released open source, i.e.). As with most systems, you first start with making sure that the API documentation is rock solid. This is what PW has done (in my observation). You pick up the API and run with it. Ryan (or somebody else, can't remember) summed it up beautifully in some post. Rather than teach someone how to put together a photo gallery, or a school website, you'd rather give and teach them the tools (API) to put together ANY type of site . You master the API, you master everything (even beyond PW since there is no templating language - it's just OOP PHP). But, there is a place for 'how to' tutorials. However, with the relatively few hands on deck compared to other similar projects, it is impossible to equally concentrate on the API documentation, 'how to' tutorials and answering questions in the forums, not to mention continuing the development of the core PW code. Hence, so far, 'how to' tutorials have largely remained a community effort. Joss has really tried to write a few. He has also posted in the forums an excerpt from his upcoming 'how to' PDF. I also have a few 'how to' tutorials in the pipeline (as you can see from my rather dormant website www.kongondo.com ). We can do with a few more Marys to tell the truth... Good point. And this is one big difference between systems that employ templating systems (like MODx) and pure OOP based systems like PW. When MODx started to crumble under my feet, I was asking myself this same question. I took the plunge into PW and here we are having this conversation. What I have learned using PW is a transferable life skill (seriously). It is like HTML or CSS. It is universally applicable. I never have to learn another templating system. This means I can (relatively easily) pick up any OOP PHP system with good API documentation were PW to disappear tomorrow.... I am happy you are not giving up yet on PW. Yes, to use it, you will have to invest time in it....but we'll be here to guide you every step of the way

Paul...if you removed /site/config.php/ you should get a 500 internal server error on both front and backend; the site should not be able to work. Additionally, if you check your /site/assets/logs/errors.txt, you will see an error logged along the lines of "Invalid catalog name: 1046 No database selected". I am guessing that you probably have several PW installs on that host and are most likely manipulating the wrong files ...

Except for name, all fields in ProcessWire Pages are custom fields . Yes, even Title is a custom field....Unless you specify a field as hidden, all fields added to a template will be available to all pages using that template....in the order you sorted them in the template. And here's a bonus for you....that doesn't mean that when you view that page (am talking frontend)...that you will see any fields automatically. Nada...you will have to output them yourself in your template file in the order you want, if you want! Sorry, I got carried away there for a minute...Enjoy!

Max, ProcessWire doesn't output any markup. So if things are appearing where you did not intend them to, then you must have placed them there . Secondly, to use PW, you will need to know some basic PHP - like was pointed out in the other thread: echo, foreach, if. You will also need to know how to use the PW API. Otherwise it will be really difficult for you. If you could invest the time to learn these, you will reap big time in the end. This is an amazing system with a lot of flexibility. But I know learning code is not for everybody . I am just being honest here and not trying to discourage you. Btw, feel free to show us the site you want to convert (or you did that already?). Might help us give you other ideas on approaches you could adopt. I hope you don't give up on PW.

Max, Nothing wrong with hardcoding the topNav. It won't change, why make it dynamic and waste resources (queries to db, i.e.)? As for the sideBarMenu, depends on how many items you want there and where they are coming from (e.g. are they simply the children of some top level pages?, etc). You can either roll up your own code (e.g., look at the example in the default PW install), or there are recursive menu functions code lying around here in the forums that you could use, or you could use our very own Wayfinder counterpart, MarkupSimpleNavigation. It is powerful, much easier to use than WF and more flexible. Depending on the approach you adopt, there are various ways to omit pages from appearing in a menu listing (in essence, in the results of a selector 'find'). These range from ticking/unticking checkboxes (checkbox field), exclusion using templates (i.e., via a selector), using the page's 'hide' setting, exclusion by parent, by IDs....just too many possibilities with ProcessWire! Google this forum for 'navigation' and have a read at the many possibilities...

Welcome to PW and the forums Charles There are various ways of reusing markup/code, ranging from the simple include('/path/to/file/') to more complex but highly flexible approaches such as those discussed on this thread: https://processwire.com/talk/topic/740-a-different-way-of-using-templates-delegate-approach/ If you are new to PHP (and that you are new to PW)...you probably do not want to start with the 'complex' approaches

@Diogo +1 for merging please . The installation is much simpler!

Hey Nico! Cool! Very simple installation!!! A small bug: There is a missing $this-> on line 71 of FieldtypeAdminCustomPagesSelect.module. It throws an error 'Call to undefined function rglob()' when trying to create the admin page. Should be $thix->rglob() A minor suggestion: Using the term 'template files' on the select can mislead some; the selection being made is technically a 'template' whose 'template file' will then be rendered . Thanks!

Valery, I think you misunderstood my post? I would go for pages (just like you showed in the screenshot) but unlike you, instead of using repeaters, I would use normal pages - one for each product. Then....for the client, instead of showing orders via pages (i.e. in your case repeaters); I would show orders on the Process Module - in a table. For other ideas, see also Pete's Dashboard module that you can add to using 'normal' PW $pages API. These are just by the ways; l agree with what you've said. Work with what you are most comfortable with as long as it doesn't negatively impact the site

Claude, This looks very nice! Thanks for showcasing it and sharing your workflow. Regarding customising the backend, the beauty with ProcessWire is that its all modules really. That makes it easily and powerfully extensible. Tailoring the backend to suit your needs could mean your client logs in and instead of seeing the Page tree, they see paginated Tabular data of their 50,000 'pages' . It could also mean they see a Dashboard or some other thing you want them to see. In other cases, even with lots of pages, you may want them to see the Page tree. It all depends on the use case. Unfortunately, presently, the 'admin custom pages module' does not work with PW 2.4 (unless it has been updated and I missed that). Alternatively, there's the Dashboard module. With that you can pretty much add what you like to the Dashboard. If not, you could develop your own Process Module...

@Valery, Thanks for the explanation. I would use pages too for each product in this case but probably not repeaters since they are not infinitely scalable. At some point, they do require a lot of resources since repeaters are just pages "hidden" in the admin and when you edit a page with repeaters, you are editing all items at once. Instead of repeaters, I would create a simple Process Module that would list the products (your pages with products) and their status in a Table. You could even have two tabs - one with new orders only and one with older orders (older versus new could be differentiated using a checkbox, for instance). I don't know how comfortable you are with coding but this is not too complicated....

Is this a product list on page by page basis? If not, if it is site-wide, why no create a simple ProcessModule? On the other thread you talked about locking the Events fields...do you want your product listing to be read only?

There you go Renobird, Teppo has stolen my thunder @Teppo - Thanks for sharing your code

Renobird, I have a strong feeling I am misunderstanding you but I'll still ask Do you mean set values at the 'template' or 'field' or a 'page' level? What sort of values/examples? PS: I miss the Goggles man!

Oh, you can mark your answer as 'best answer' aka topic solved

I am guessing a fraction faster (I could be wrong) just because it is more specific....but in a real world scenario, especially in the backend, maybe it is not a big deal...But, doing it that way also reminds you what exactly you were looking for or in case there are multiple admins on the site, just to make it easier to know what's going on...

In that case, Teppo's code should work. It works for me as follows.. return $page->parent->parent->child('name=tags')->children(''); ..and in that page field, under "Input" -> template of selectable page(s) I have selected 'tag' (the template of all tags (A, B, C, D). This last bit is unnecessary; the selector still works but I'd keep it just to optimize the find... Edit I posted a second after or two after you did....Yep. that works too..but my selector won't bother with looking inside 'categories' or 'articles'; It will go straight for 'tags'....I think ....not a big deal probably

I think that error means the selector did not find a page to return. This could be because it is hidden or unpublished or the selector is just wrong . I have re-read your post and not getting you clearly. Could you explain what you want to do using the pages in your tree (above) as examples? E.g. "I want to select the children of Topic A when I am editing the page Topic A"...i.e. be as specific as possible.

@marcus...I think a get is better for a single page no need for a find...

It's there in the Cheatsheet...enable advanced and voila!

Hi Sunny, That's some serious photo dashboard (koken cms). Although creating a PW admin theme is not difficult, for usage such as you require, the normal route IS NOT to create a new admin theme, but to create a Process Module. Such modules extends the PW admin. In case you didn't want editors to see the normal PW admin on login, you could make their logins redirect to your Process Module. Edit: Also have a look at Pete's Dashboard module that you can build on...