mr-fan

Actual i've to build a prototype with usermanagment and useractivity and for rapid prototyping the template way is not that bad...at least for me. I use template files for routing to the different actions so all template files stay as clean as possible. example: ---app_root (page for the app available under www.my-site.com/app/... -----login_page (~50 lines code) -----logout_page (~ 10 lines code) -----register_page (~400 lines - two way auth...) .... The separated code of the template could easy splitt in modules/classes later. I using https://bitbucket.org/pwFoo/formhelper/ Regards mr-fan

@jmartsch there is a Lister Pro Action for this export as CSV i thought?

Maybe the APIGen from Kongondo helps a bit... https://github.com/kongondo/ProcessWireAPIGen And there are snippets from sublime regards mr-fan

as always more information...PW Version, PagetTable Version, PT Field settings.... best regards mr-fan

I read that docs "properly", too and find out that the main magic with PW is something strange like $page and $pages and of course "selectors" hmm foreach a category...let me see where i as noob could find such things...;) https://processwire.com/api/variables/pages/ (with some foreach examples) So ok pages are something like "WireArrays" what is that im curious maybe i should read this one... https://processwire.com/api/arrays/ (even there is a foreach example) Don't get me wrong but my heart is fighting a little for every newbies....and with your posts the other newbies get a wrong view... Take a breath - take the time to experiement yourself with the API in combination with YOUR HTML of choice at start with AdminCustomPage you don't have to use MarkupModules or Core UI Elements...you are free to build what ever you want and pull the data with the PW API in your Output....and ask question nice and calm. There is no way to do things right so there is no doc that say "step 1 - step 2 - step 3 - finished" Your only get many many many options to get to your goal - you have to choose yourself All that options are not documentated only the API and the whole core codebase is there....plus tutorials....plus a real great forum with posts from 2012 thats code is today working good!!! ->plus helpfull and friendly people here that offers everyone help! If you had read throw my links and studied the code from the MarkupAdminTables you have had found things like this one: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Markup/MarkupAdminDataTable/MarkupAdminDataTable.module#L171 //for the lazy people i cp all important here... if(count($this->actions)) { $out .= "\n<p>"; foreach($this->actions as $label => $url) { $button = $this->modules->get("InputfieldButton"); $button->href = $url; $button->value = $label; $out .= $button->render(); } $out .= "\n</p>"; } Ohh i learnd that i can add action buttons to the rendering of the MarkupAdminTable module...nice and second i learnd how to create UI buttons with the Core Inputfield...from reading simple the code and don't search some documentation and the great thing in PW is i can use that Markup everywhere frontend, backend.... Documentation "teach" you nothing - documentation only describes what and how you can to do with software....like i wrote in PW you only need to learn and use the API and you can do all how you want it be done.....this is the point of the matter. There is no and i hope will never be a documentation that teach me how i have to build up my system or programm my websites and applications - this task is on my own. Since this is a forum of a free opensource software, no one has to aswer carp and claiming questions in his sparetime...there are no noobish questions in this forum - al things get sorted well with this community but always with a friendly and dedicated attitude on both sides. Sorry for my harsh words but all your post seems to be impatient and reproachful - exept i'm mislead your words. Best regards mr-fan

There is no need for more documentation...you can simple create Admin pages that using a simple template file without creating a own process module. THIS is the way every newbie add admin pages/dashboards with simplest PHP... There is absolute nothing fancy. All Adminpages need a ProcessModule. AdminCustomPages is as plain as simple in around about important 15 lines of code the Process connects the created Adminpage wich Template file under /site/templats/ should called....and search for some related CSS/JS files... The rest (i think what you mean - the tables and the rendering stuff ) is all basic Processwire UI Coremodules or other such called MarkupModules that simple rendering a UI - like you see in the great example from BitPeot you can call it simple like: //render a table for me $table = $modules->get("MarkupAdminDataTable"); //fill $table with stuff //render a PageList or use some Inputfields and you could use even the $form creating from the API...search for it in the forum there is //only one important topic that has all informations //or simple use PHP to render what ever echo "FooBar"; And one important tipp - i don't know how much well documenated other projects (you mentioned some above) are, but all PW core modules and many third party modules are very very well documentated in its codebase itself. For you as experienced dev this should be great news...;) https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Markup/MarkupAdminDataTable/MarkupAdminDataTable.module https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPageList/ProcessPageList.module https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Inputfield/InputfieldCheckboxes/InputfieldCheckboxes.module I have to admit that processwire is not for everyone a conclusive concept from the start. But personally for me as "longtime PHP scrub", i don't get the the basics of OOP programming until i found PW - where OOP is not only a programming concept - it is the whole system. Even it was deadsimple for me to create own modules, as textformatters, markupmodules and many other stuff...but in the most cases i'll stick to simple PHP template code that works. On other CMS/Frameworks you need complex basic structures to build up on them, with PW you have to build your own structure with the great API and how complex you like it. regards mr-fan

@Galo for abbr options you have two "semiautomatic" modules that provide abbr support: without CKE working on all Processwire textfields you choose and a central managment of all your abbr's regards mr-fan

A tipp for your setup. If you choose a parent page that is not under the /admin/ page you could use this snippet at the start of every block_template to hide pages from frontend access via url: <?php // the pageurl is hit this template file directly. if ($page->url == $_SERVER["REQUEST_URI"]) { throw new Wire404Exception(); // show 404 page } But put everthing under admin is better solution...i don't read the docs to deep at start, too I use this module as kind of WYSIWYG blockbuilder on most installations and the largest amounth of blocks is ~ 300 for now....pages are scaling very well in PW. Some drive sites with several thausand pages under one parent... regards mr-fan

http://lmgtfy.com/?q=processwire+how+to+hide+the+pagetree+and+pages+tab%3F

no like in my example "Reply to Dashboard (Redux)" you could add "action" buttons to your table of estates like: $table->action(array( 'New Event' => $config->urls->admin . 'page/add/?parent_id=XXXX', 'All Events' => $config->urls->admin . 'page/events/', )); even further you could use a PW feature that use a modal to edit: //call the script for the modal $this->modules->get('JqueryMagnific'); //try to add simple modal=1 and a lightbox class to the a tag with this jquery script $(document).ajaxComplete(function() { //add trigger class and modal setup $('.yourFancyUILinkToAPage a').each(function(){ $(this).addClass("lb-edit").attr("href",$(this).attr('href')+"&modal=1"); }); //setup lightbox $('.lb-edit').magnificPopup({ type: 'iframe', disableOn: 0 }); }); I used this function on a own build Pagetree but this could be adapted on every "edit" link you wanna use a modal. So your client get the normal PW PageEdit Form and there is no need for a own form. But own forms created with the API are possbile, too.

You are right basically there is no problem with that concept...it is only depending on dataset and future features or changes on the project. I'm personally always wanna have a clear structure so same things belongs to same things - this is what pagefields are for. And the pagetree is nice - but on a client applicatipon not always the best and flexible CRUD system for custom things and access. For normal website clients a pagetree is very easy to grasp and administrate - but special content/systems need a own UI - just my opinion. And at least this is very easy possible with PW, even if you don't invest the little money on ListerPro you have many options to use the PW UI for your dashboards and needed stuff. Like i always wrote with PW there is no single way to go, it depends on the knowhow, the usecase, dataset and personal opinion how you solve a problem. But first you have to know all the options....;)

@Robin S no this module only works if estates are as childpages under every client! If you have all estates under one parent and separate with a pagefield this would not work... So if you grasp the concept it is a very ambitiously to get a real "client" based application running...;) I will provide you again some links and advice - but i've to say that is is very important not only grasp the concept if you wanna build a working solution...there are many estate applications out there since this is a $$ business I provide very often on more complex sites a simple stripped down admin page for special users...with AdminCustomPages module. With Processwire there is no module that does the heavy lifting for you, but PW IS the tool that makes heavy stuff beeing fun.....this is the basic concept of PW. No "ready to use" solution but a "ready to build" Workbench! If you have deeper problems on this topic you can PM me or you can use this board, too: https://processwire.com/talk/forum/22-jobs/ best regards mr-fan

Some questions... 1. you mean the pagetree (user viewing pages in the backend) 2. estate_user_id is a pagefield? 3. you really wanna go with the pagetree for your clients to manage their estates...? (I wrote some posts above about ListerPro and own Admin Dashboards....) It would be much more simpler to setup a own admin page and show the needed pages depending on the $user that is logged in....than bending the pagetree... regards mr-fan

1. If you use the admin the follwing topics are interesting: This would provide a solution if every user has it's one branch of estates...would be more complex to setup than all estates under one parent. Take a very deep look in ListerPro - you could use it as a admin page for your users so that the even won't see the pagetree and get a UI for managing their estates: https://processwire.com/talk/store/category/9-listerpro/ You could give access to a admin page with a lister that provide searching and filtering, add new and edit interface depending on the user. If this commercial module is no option you could setup a own admin page: you could create a admin page with a template file for the logic without that you have to create a process module... with ProcessDashboard you have another option for a own dashboard that you could provide for your users... 2. A Pagefield is just a simple connection - if you know database structures you could build 1:n, 1:1 and n:n connections with a Page Field the different select inputfields are depending on the usecase - but with the great PW API and selectors you could get any data on any place that is related via a Page Field In your example for the connection of the user and the estate you even don't need a Page Field since you could access the createdUser so on the $pages->find for loading all estates of a user you could use this connection.....it's just usefull for cathegories, tags, options of your single estates!

You could this accomplish....the question is what route you wanna take like.... -> Did you plan to use PW Admin for the users as administration or would you create a frontend presenation of your "application" with frontendedit -> you can have all estates under one parent and connect them to the user that created the single estate search for page field type - this is one of the centric concepts of PW you build your content and separate it in logical parts (pages, templates, url segments) and connect them with pagefields (single or multiple selects)

1. Answer: yes https://processwire.com/about/sites/categories/real-estate/ 2. Answer: depending in depth of what kind of content you will manage/provide... regards mr-fan

Ok first one - url segments are nice - if you set them on a url and load that content you've access to all segments that are provided.... or you go with get parameters: http://demo.processwire.com/search/?keywords=&city=ann-arbor&height=250-500&floors=&year=&submit=Search But maybe i 'm not really understand the question - more details would be great... regards mr-fan

Just short from mobile... Search the forum (viaGoogle) for structure content kongondo... there is a great topic on this kind of problems. And search for usage of page fields as connector of your data. For me at the first impression you have to separate three things. Projects - can have several phases, users, events Phases - related to the project connected users and events Events - related to phases, users and projects The user template have multiple page selector for projects, phases and events of a user.... Best regards mr-fan

If your problems belong only to some Admin pages like the pagetree you could even change the used Process for that Adminpages...for example you could replace the ProcessPageTree with ProcessLister and there is no more pagetree but a full configurable Lister running....just a hint. More details of usecases or problems would be helpfull....

@Robin S is right - you wrote tausands of chapters on one book....than i forgot one really big additional option in managing chapters right for editors....;) https://processwire.com/api/modules/lister-pro/ With lister you can setup a view where someone can select the book - or search for it and CRUD chapters... The Profield Table can paginate, filter and sort, too so this would scale for many chapters. But one the first run i would give book/chapters a go and use BatchChildEditor. With BCE you could create dummy data, pages via CSV import, too!! Thats the propose i use it in some projects. Most important thing choose wise and have fun!

Ok it is may confusing while you have the UI in mind...i would present you a different view. Basically you are right. You can setup your app like you wrote: ->book -->chapter1 -->chapter2 ... as childpages of the book. As oneToOne every chapter belongs to only one book. In the blog example of @szabesz a blogentry chould change tags, cathegory and so on but your chapters always belongs to one book... So you could use something like to easy edit the childpages (chapters) of a book: On the API side you can check if a book have a childpage (so a chapter is there) and only if this check is true show the book...on the admin you can show the editor a message with a hook on page save that there is no chapter and they have to create at least one... Example for hooking after page save: UI Alternative1 (The real problem with PW is that there are tons of alternative ways to go....at the start; - ) You could take a look at the great Table field from the Profields - it is commercial but have a lot of pros on User UI and datamanaging of such setups. It uses pages in the background but as fieldtype you could add items within the book template. Have a read: https://processwire.com/api/modules/profields/table/ https://processwire.com/blog/posts/fieldtype-pagination/#example-profields-table https://processwire.com/blog/posts/3.0.27/#whats-new-in-profields-table-v14 UI Alternative2 Use PageTable field for your chapters. It uses pages, too and your editors add entries on the book template, too. It could be easy set to put the chapters as childpages or under chapters/chapter for managing all under one root. The pages stay connected via the PageTableField. PageTable Field is a little bit different to Table since you can setup more complex editing things and change the single pages on the default edit path, too. Table and the default Repeater field are both repeater fields for less or more complex entries that belong to one page, while only the table field provide the options that you need (hundreds or thousands of chapters of a book) pagination, filtering, scalability and so on. PageTable and the former mentioned Repeater Matrix are something like a provided UI for editing real pages with templates and fields without restrictions. Take a deeper look: On the first projects with PW take the time that you will save while developping to research how to start since this time is priceless. While you get deeper in the rabbithole the more fun you will have best regards mr-fan

check out the topics and the pic of this post if you wanna go further the dark side of content blocks....;) with PW it is easy to build a blockbuilder that really don't mess your page since on my websites i have full control to the contentblocks that a editor can use... regards mr-fan

Adrian is right....my github account is only the host of the module...he is owner of the credits on this smart piece of code....;) But i haven't tested the module with 3.x version...since there are a lot of changes on the image handling....i don't know if it works. regards mr-fan

Happy Birthday!

For this proposal Ryan build a great module that works really good: https://processwire.com/api/modules/profields/autolinks/ From my point of view Ryan is right on his choice to let only admins set the terms if an automatic is running... The mixture of user defined terms and automatic replacement could be very dangerous. But you could simple fork and change the module and switch from the ||regex|| to a exact search for the terms and replace them automagical.....since i'm a "second hand" webdev + living on a farm in south germany = summertime is some harvest and less time for the desk best regards mr-fan