Jump to content

kongondo

PW-Moderators
  • Posts

    7,374
  • Joined

  • Last visited

  • Days Won

    139

Everything posted by kongondo

  1. 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 ...
  2. 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!
  3. 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.
  4. 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...
  5. 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
  6. @Diogo +1 for merging please . The installation is much simpler!
  7. 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!
  8. 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
  9. 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...
  10. @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....
  11. 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?
  12. There you go Renobird, Teppo has stolen my thunder @Teppo - Thanks for sharing your code
  13. 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!
  14. Oh, you can mark your answer as 'best answer' aka topic solved
  15. 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...
  16. 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
  17. 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.
  18. @marcus...I think a get is better for a single page no need for a find...
  19. It's there in the Cheatsheet...enable advanced and voila!
  20. 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...
  21. The idea here is get the basics right; not try and get to know everything, especially the deeper stuff in one swoop! Rome wasn't built in a day; but it was built "correctly" from the start; The builders got the basics right Yes, but play "in your league" (no offence meant here). You are trying to play in the big league but you are still a rookie; going by your questions, we can tell you are not ready yet. Rookies need time to learn. So, play in the minor leagues first, then advance upward....I promise you, it will be more enjoyable for you this way... In essence, yes build, but build slowly, build the right way with simple tools first (forget PHP functions and the rest, for instance) - concentrate on the PW API but not the whole cheatsheet! - just $page, $pages and selectors for starters. As you build this way, also play but play according to your current knowledge (level)... I think I have said enough....based on my own experience. Final decision is up to you, of course. I am out....
  22. Uh, this is already available when debug=true ...though a bit wonky in a few use cases...You need to hover on the arrow on the right of the field when editing a page. Otherwise, some of your suggestions are neat
  23. @Ralf. The main thing here is first to deal with the parentage issue. The rest - description, owner, price, birthday, etc. are simpler. They are just fields that you can have in the horses template. The pedigree can either be single page fields, or you can create your Page's Tree to reflect pedigree as you've shown in your first post. Just to repeat, about clickable, like Martijn said, you can enable and disable that. So, in a nutshell - ALL horses must have a page in the backend (in your admin...i.e. as children of the page "horses" who is a child of "home") BUT not all of these horses pages' will be viewable in the frontend. For such, you will not output their links to the pages and if your web visitors try to enter the address to that non-clickable horse manually (phew! - that was long!) - they get a nice 404 page not found . if you don't know a horses parents, there's the Null Martijn suggested...
  24. By the way, if you have too many horses to choose from in the page fields (and also to minimize mistakes), you can instead have two templates for the horses: "male-horses" and "female-horses". Then force the page fields "father" and "mother" "Template of selectable pages" to use these templates respectively.. This also helps if you want to output say, only the male horses, etc...You get the idea
×
×
  • Create New...