apeisa

I have it working nicely... almost One little problem that I cannot figure out. For some reason this code gives me HTTP-error 500, but only once (first time it runs). Probably some silly error (I create stuff on wrong order or something similar..? Or save() doesn't return the object I assume it returns? Ryan, any ideas what I am doing wrong? I have also attached full module if anyone is interested to try. There is one new feature and it is quick collapse-enabled sitemap to show where the current page is located and to quickly move around your site. I know this code could be cleaned up a lot, but be gentle - I am just learning this stuff private function _createAdminBarPages() { $abName = "adminbar"; $abFieldGroup = $this->fieldgroups->get($abName); $abTemplate = $this->templates->get($abName); $abPage = $this->pages->get("/processwire/{$abName}/"); if(is_null($abFieldGroup)) $abFieldGroup = $this->_createAdminBarFieldGroup($abName); if(is_null($abTemplate)) $abTemplate = $this->_createAdminBarTemplate($abName, $abFieldGroup); if(!file_exists($abTemplate->filename())) $this->_createAdminBarTemplateFile($abTemplate); if(!$abPage->id) $abPage = $this->_createAdminBarPage($abName, $abTemplate); } private function _createAdminBarFieldGroup($fieldGroupName) { $abFieldGroup = new Fieldgroup(); $abFieldGroup->name = $fieldGroupName; $abFieldGroup->add("title"); return $abFieldGroup->save(); } private function _createAdminBarTemplate($templateName, $abFieldGroup) { $abTemplate = new Template(); $abTemplate->name = $templateName; $abTemplate->setFieldgroup($abFieldGroup); return $abTemplate->save(); } private function _createAdminBarPage($abName, $abTemplate) { // create /adminbar/ page under admin $abPage = new Page(); $abPage->template = $abTemplate; $abPage->parent = $this->pages->get("/processwire/"); // TODO: How to remove hardcoding admin url?? $abPage->title = $abName; $abPage->name = $abName; $abPage->status = 1031; // hidden & locked $abPage->save(); // after that create /adminbar/adminbpar-sitemap/ $abSitemapPage = new Page(); $abSitemapPage->template = $abTemplate; $abSitemapPage->parent = $abPage; $abSitemapPage->title = $abName . '-sitemap'; $abSitemapPage->name = $abName . '-sitemap'; $abSitemapPage->status = 1031; return $abSitemapPage->save(); } private function _createAdminBarTemplateFile($abTemplate) { copy(dirname(__FILE__)."/pages/sitemap.php", $abTemplate->filename()); } AdminBar.zip

Yep, now it works, I don't know any more missing replies. Strange (but good in this situation) that those showed up in reply mode.

Offtopic: This is a mystery topic. Two replys are missing (Adam's and one mine). I see them only when I click reply. Topic view shows 5 (after this one 6) replys, but there is only 3. I don't see them even if I log out or use different browser.

Adam: Case might be intranet or some other special environment. I personally feel bad every time when I see any code in textarea. Even if it's css. About unused images: can you describe the need better? Images that user add's but never uses anywhere? Or images used in templates/css but edited away in some point?

I actually haven't read this before. Nice to know the plans. I think most important things are: Simplification of the roles/permissions system. => Currently roles are only part in PW basics that I didn't understand right away or quite fast (I still don't understand them ). They also slow down module development in many cases, and using pw where complex user access is needed. Continue posting new documentation to processwire.com => Documentation is very important. Current documentation is clearly written and extremely helpful, but some important parts are still missing. I see here two paths: core functionalities for mod developers and advanced site builders, like $templates, $fieldgroups, UA, but also "newbie tutorials". The latter is something that community could easily help and I really believe that it could draw more people to PW Localization support for non-English languages. => Very important. I think that PW supports pretty good options to create multilingual content, but what is needed is admin languages, date formats etc. For some users though this is unimportant or completely irrelevant. Built-in user form processing with admin tools to list/search/read/update/delete submissions => Yep, very often needed and there was some nice progress in this sector recently! These are very powerful features, that I really hope to see in PW, but I think that none of these should go before upper list (just a personal preference though ) Page preview before publish (i.e. page drafts) Strong versioning system for pages. This would also include multi-level undo and a page version comparison tool. Workflow functions whereby Templates can have custom statuses assigned which affect the state of the pages using them. JSON page-selection web services for use by admin modules Customizable page "channel" view, in addition to the sitemap view currently in ProcessWire (Admin > Pages). Various improvements to the FieldtypeComments module(s), including documentation! And "nice to have" list: Conversion of some core code into plugin modules Google Maps Fieldtype module Autocomplete Inputfield for use with Page Fieldtypes Last, but not least: "not for me list" : Tagscript parser that enables you to access most Page/Pages-related API capabilities via a tagscript syntax.

I don't know why, but this message from Adam only showed on reply view - but topic list showed it as latest reply. Weird thing. Hope it shows now, since that is clear answer. (EDIT: Now I see Adam's message too) I actually answered (or tried to answer ) this question on my first post and jumped to examples in next. I think that easiest examples are on http://processwire.com/api/templates/ page and under header: Finding and loading other pages from your template file

I haven't looked more further than just the tried the demo and read features, so I'm not saying that this is better/worse from others. I'm not sure if I understand your comment right, but doesn't this support multiple files selection & background upload? Also, it also has graceful fallback, so it works for legacy browsers also. Of course since this isn't flash/java based it means that to get all the bells and whistles users would need to have a good browser. Or is that the problem? Should it be all-or-nothing solution, so we can count that it works same way in all browsers? What is desired browser support level for current pw admin btw?

I made some progress here. Most important thing first: PW source is very well documented and it just makes sense! After half an hour I started guessing method names and usually got them always right I have now version working, where I create adminbar-template (with fieldgroup & title field), adminbar-templatefile & and finally create the page. I'm not sure if this is right way to go, but I see huge benefits this way: Template-files that adminbar uses goes to site/templates/adminbar folder, so they are easily customized per site basis We could have ie. "Information for content editors" field that is showed everyone who is editing content etc. Maybe more settings per different view etc? This gives full control to create modal views as I like them to be - easier to develop than hooking. Of course there we have to be careful not to re-invent the wheel and keeping UI consistent with other aspects of PW Only negative things I can think of now are More templates, more pages, more templatefiles... But probably just a good thing, if those can be visible only to superadmins (I don't know yet how UA works) This was quick hack, but if Ryan confirms that this is not worst way of developing AdminBar further, I'll probably go forward and implement this at least on the views that current admin doesn't provide (I know correctly this means only the "full sitemap view" so far).

http://aquantum-demo.appspot.com/file-upload This might be worth trying? Just played with demo, that worked nicely. Slow connection + big files = progress bar needed.

I do not know how I missed this list on first read Here is few examples (code is not tested and your template names are probably different): List of featured portfolio items (I haven't actually played with images yet, but that is from example template): $featured_from_portfolio = $pages->find("template=portfolio_item, sort=-datetime, featured=1, limit=5"); echo "<ul>"; foreach ($featured_from_portfolio as $portfolio_item) { $image = $portfolio_item->images->getRandom(); $thumb = $image->size(500, 300); echo "<li>"; echo "<a href='{$portfolio_item->url}'>{$portfolio_item->title}</a> ({$portfolio_item->datetime})"; echo "<a href='{$image->url}'><img id='photo' src='{$thumb->url}' alt='{$thumb->description}' width='{$thumb->width}' height='{$thumb->height}' /></a>"; echo "</li>"; }; echo "</ul>"; This snippet first finds pages that have "template=portfolio_item" and field called "featured" is checked. It sorts them by date (template has field called "datetime") and limits results to 5. After that we loop through these max five portfolio_items and show results. You probably would have own image field for this usage like "featured_image". So this code assumes that you have: Template called portfolio_item portfolio_item has at least fields: title (it's always and cannot be removed), datetime, images, featured Lates blog entries: $newest_blog_posts = $pages->find("template=blogpost, sort=-datetime, limit=10"); echo "<ul>"; foreach ($newest_blog_posts as $post) { echo "<li><a href='{$post->url}'>{$post->title}</a> ({$post->datetime})</li>"; }; echo "</ul>"; Hope this helps a little bit to right direction. I haven't actually developed any real sites with PW yet, so don't trust my word too much

Hi Rebecca and welcome to the forums. That is very easily done with PW, through simple jQuery-style API. Most of the information you need can be found from this page: http://processwire.com/api/templates/ And there is header: Finding and loading other pages from your template file. After that if you provide some more information, like what fields you need and from what page/template, I think many of us can help you further.

Yep, that was it! Tested it quickly and seems to work very well. Endless possibilities here again, very nice!

FormTemplateProcessor doesn't show up on Admin > Modules at all. I have the file on /site/modules/ folder.

Ryan: nice! Tested it quickly: got this error Call to undefined method stdClass::render() (line 19 of C:\apache\htdocs\pw\site\templates\page.php) This is what I have on template file: $form = $modules->get('FormTemplateProcessor'); $form->template = $templates->get('contact_form'); // required $form->requiredFields = array('title'); $form->parent = $page; // optional, saves form as page echo $form->render(); // draw form or process submitted form I have template called contact_form, which has only two fields (title & body). There might also be typo on your example: last $form is $contactForm

These are just thoughts, but my first idea was that it would provide full site map (well, maybe not full if there is very deep levels..) in open state, show clearly where the current page is. Then of course links to move to other pages. Probably no need to edit, move etc (since these are easily done through real admin). In short: to provide quick look over the whole site and where the current page is.

Martin: Thanks! Ryan: what would be best approach, if I would like to create sitemap for AdminBar? Or any other "customized" page? My initial plan is this: Check if there is template called "AbminBarPage" ->if not, create template (title & body fields) Check if there is page /adminbar/sitemap/ -> if not, create page -> put needed code into body It would be probably good idea to actually produce each view as AdminBarPage, then this module wouldn't break on changes on admin templates (or if some site has custom admin etc).

I updated license information. GPL2 it is, just like PW.

Great to hear that you guys think this is important too. My two cents Default markup is needed here, it should be plug and play Of course it would be nice to have full control of markup when needed As Ryan said, template editor is actually form building (we define fields, admin site shows form for us). I think that the UI with current template editor is easy enough for non-technical content editors - so we should use that as much as possible Very interesting to see your findings Ryan about using Inputfield modules to create front end forms.

To be honest: you probably wrote more code than we did So thank you and congrats to you also! I will.

I am looking for something similar that webform is in Drupal. Some way to admins to build forms (contact form, order form etc). Entries are saved to database and send email if wanted. Easy to use, most basic fields only (text input, textarea, email etc) at first. Any thoughts how this should be done?

Also fixed the problem when changing between add / edit modals. I think we have now pretty stable version, so please let me know if there is some problems. Only known issues are UI issues in IE (all versions).

True, I will work on this next. EDIT: Now "view" link is hidden Also true. I would actually like it on real admin view also - there is many times scrolling involved, even when updating title only. Please let me know if you implement this on admin, so I do not re-create it on modal.

Ok, there is a bug now (just noticed). If you first click "Edit page" and after that "New page" then it won't work. I made it so that we do not reload iFrame or manipulate DOM everytime we click edit button. But I have to check for iFrame state and reload iFrame on cases where we switch action. Or easy solution: refresh page when we go off modal... I thought that it could be nice feature to be able to start editing -> view original site -> continue editing -> save. Dunno.

And that was right... used svn magic on git... It was lamest release ever, but now it should be working. Ryan: Probably best way to bundle this is like this /AdminBar/ readme.txt I refactor soon.

Okay fellows, here we go: https://github.com/apeisa/AdminBar