Leaderboard

This is updated/version of the AdminDocsTab module as was posted here: https://processwire.com/talk/topic/11803-admindocstab/ (that one is now obsolete) https://github.com/outflux3/AdminHelp AdminHelp module for ProcessWire Processwire helper modules for managing site documentation. Currently alpha state - please use with caution and report all errors. Instructions There are 3 modules included with this: the master module holds the settings for the other 2. This is a helper module which expects you to have already setup a hidden part of your page tree* to establish your help documentation, using any template (e.g. 'help-doc') and a body field (ckeditor) (*or you can run the setup and it will create these items). The help-doc template does not need to have an output template, as the module will only echo the body field inside the admin. In addition this 'help-doc' template requires "template select" field (separate module) which should be named template_select. (if you run setup it will create this). To have a global help page, which renders all of the help docs in an accordion view, you can install the ProcessAdminHelp module, which will setup a page to view the help docs, under setup. Help Setup Module (AdminHelp) This is how the setup module looks before setup is completed: If you use the automated setup, it will create the field, templates and pages, and will auto-set the module configuration: Example Help Tab (when using AdminHelpTab) Admin Help page (ProcessAdminHelp) This shows all help docs in accordion. (it is capable of displaying child pages also but this is not currently implemented in the module due to the family settings of the default templates). Accordion opened: Features Summary: Manages settings for the help templates (help-index, and help-doc), which enabled users to add new help docs where applicable; these can already exist and be named whatever, you just specify them in the setting. Getting the help/docs tab to show up in the right place (based on user preference template selected on the help doc). Has it's own scoped CSS styling that makes the documentation readable and engaging; has some @import fonts, and also rules to make text layout look correct in PW admin (paragraphs, lists, headings, blockquotes etc.) Makes it easy for site editors to add their notes, mods/edits/enhancements to the docs (edit button - currently only enabled for Superadmin - this can be made a setting based on user feedback). Using the secondary process module will create a 'Help Docs' page under Setup where you can view all of the docs in 1 place as an accordion. (could be moved somewhere else) There is also an automated setup that can run, where it will create the field, templates, and pages for you to get started. This module is probably optimized to handle no more than 10-15 or so help pages; if you needed more than that, the Process module may need to be changed to work differently. Most sites I do need around 4-5 help pages. *If you don't want to load those extra google fonts in your admin you can modify the CSS to your needs, e.g. remove the @import and then change the few lines of css that reference those; Once there have been a few testers, I can see about adding this to the modules directory in a week or so.

For people who want a simple solution out of the box, I would say ProcessWire is not that kind of CMS and that's a good thing. I see ProcessWire as a developer-oriented tool for building custom, complex content websites that have unique requirements and that should be it's strength. CraftCMS and ExpressionEngine fit that niche as well. If ProcessWire were to become a CMS where themes could be swapped at will, I'd imagine that would first pose some technical challenges that would need to be resolved. For example, to what extent does a theme dictate field/template structure, and if someone were to switch to another theme, how would that work? Nico's WireThemes proof of concept module has a nice way of going about that. It's similar to how FormBuilder can map a form's fields to a page's fields when using FormBuilders option to save submissions as pages. When it comes to WordPress and premium themes (like ThemeForest), once you're on a theme, you are stuck with it. No easy portability. Not to mention, each theme is like a CMS within WordPress itself, especially with the trend of mega themes that have recently become popular. Then when add a few plugins to the mix and you'll probably have all kinds of conflicts. Although WordPress is still the king of CMSes for ready-to-go themes, I would say that WordPress is going to be losing its dominance in that arena given the new generation of remotely hosted content management systems, like SquareSpace, Wix and Webflow. Those companies are doing very well because they really cater to people who want something up quick, cheap, easy and with a small learning curve. No coding required. It seems that WordPress (.com at least) is stepping up their game to challenge that. Their new admin system and Jetpack are good examples. Lastly, being the McDonalds of CMSs will cheapen the image of ProcessWire. I do think however we should be attracting advanced WordPress developers. In short, anyone who uses any tools from Roots.io, Underscores, Advanced Custom Fields, WP-CLI, or similar. There are many talented people in those circles who for reasons beyond me, still use WordPress.

I don't have an answer to this question, but I suspect it has to do with the very nature of PW that attracts people that are more focused on work and GTD and less worried about social media. At least I like to think that's the reason

I agree with you that wordpress and processwire are totally different systems in every aspect. And if PW tries to emulate WP it will lesser its quality and overal developer hapiness. My point here is we could make a special market for site profiles that shows a starter package for developers to build on, like those you mention Roots and Underscores are starter packs for wp theme builders. Well documented, expertly crafted site profiles that will lower the barriers for beginners and save time to seasoned pw developers. Now there are site profiles, but I feel that they can be improved in documentation and structure.

Hehe, I chuckle when people write "bare with me" which would be a whole different picture

Hi, I read the blog articles and many planned improvements and new features. At the moment I do some tests with devns branch and maybe switch over to it. ProcessWire's front-end framework (for the admin) I like the PW backend. It shouldn't be more complex or slower. Simplify it and maybe reduce dependencies (jQueryUI?) to make it faster. If modules like inputfields (frontend file uploads), login (swap out backend admin messages), .... will be modified it would be great to keep frontend usage in mind. I know that isn't the PW intention, but it would be great to reuse login module, form api... Other systems deliver "basic modules" like login, register while developers have to write custom code or use 3rd party modules. I like to write my own modules and learn more about PW, but more stable frontend useable modules (= existing core modules used in the backend) would make PW more attractive for new users and could increase the community.

I have just found this css framework (called Responsee III) the other day (actually, I've been looking for something like this for a while). It is not as "bloated" as (say) Bootstrap or Foundation, so it is easy to figure out what is behind the scenes, as it uses vanilla css so no sass/less or similar is used. This framework is not re-written from scratch every second year either. I tested one of its v2 based demo website by replacing the framework's files with the new versions found in v3, and nothing has changed on the frontend, so even upgrading the framework was as simple as replacing some files. A framework like this would be a good choice to be used for this "quick start site profile". People can customize it easily by using their own "custom.css" to overwrite the rules. Besides the css framework, the profile should support something similar that WordPress does right out of the box (standard blog features with categories). I also support (actually I am implementing my own PW version) a variation of the delayed output, when (e.g) basic-page.php only does this: $layout = wireRenderFile("layout/basic-page.inc.php"); and basic-page.inc.php contains the alternative syntax style template code, which is often preferred by beginners and people coming from WordPress and similar... Edit: I forgot the name and the link of the css framework, so I just added it...

yeah, i think it would be cool to have a completely pre-built demo site with filler content, sort of like the old Joomla 'quick start' model. the expectation would be that this is for people who only want the features as shown on the profile, and no custom development; could make it easier to promote it to clients with lower budgets, instead of sending on their way to WP or SS..

I don't think it's possible with a selector to recieve pages that have one specific month (across years). Your solution is the only I can think of. However you could write an helper function to just be able to use $pages->findPeopleBorn(9); to keep template code thin. A module with a hook $this->addHook("Pages::findPeopleBorn",$this,"findPeopleBorn"); which then has a public method findPeopleBorn($event) that returns results would be a good way to do this. See "HelloWorld.module" for example. One way to archive it without going through all users would be to separate day,month,year into their own fields. This would be easy to then query all pages with a specific month via a simple find(selector). Or a custom mysql sql query to recieve the id's and load the pages from that. Assuming the date field is called "birthdate": $tmplID = $templates->get("people")->id; $month = 8; $query = " SELECT field_birthdate.data,field_birthdate.pages_id FROM field_birthdate LEFT JOIN pages ON (field_birthdate.pages_id=pages.id) WHERE (EXTRACT(MONTH FROM field_birthdate.data) = $month) AND pages.status < 2048 AND pages.templates_id=$tmplID ORDER BY pages_id"; $res = $db->query($query); if($res->num_rows){ $ids = array(); while($u = $res->fetch_array()) $ids[] = $u['pages_id']; } $ids = implode("|",$ids); $people = $pages->find("id=$ids"); foreach($people as $p){ echo "<p>$p->title</p>"; }

A quick tutorial how to create file downloads using pages You will be able to create a new page using template "PDF" (or any you setup), upload a pdf file. You then can select this page using page fields, or links in Wysiwyg. The url will be to the page and NOT the file itself. This will allow to keep a readable permanent unique url (as you define it), unlike /site/assets/files/1239/download-1.pdf, and you'll be able to update/replace the uploaded file without worring about its filename. Further more the file will also have an id, the one of the page where it lives. Clicking those links will download or open the file (when target="_blank") like it would be a real file on server with a path like /downloads/project/yourfile.pdf. You'll be also able to use the "view" action directly in the page list tree to view the file. Further more you'll be able to esaily track downloads simply by adding a counter integer field to the template and increase it every time the page is viewed. Since the file is basicly a page. This all works very well and requires only minimal setup, no modules and best of it it works in the same way for multi-language fields: Just create the language alternative fields like "pdf, pdf_de, pdf_es" and it will work without modifying any code! Still with me? ok PW setup Download folder: Create a template "folder" or "download-folder" with only a title needed. Create pages in the root like /downloads/project/ using this template. Setup the template for the pdf files 1. Create a new template in PW. Name it pdf 2. Goto template -> URLs tab and set the URL end with slash to no. (So we can have /path/myfile.pdf as the URL) 3. Create a new custom file field, name it pdf. Set its maximal count to 1 under -> Details tab. 4. Add the pdf field created to the pdf template. Easy. 5. Create a new "pdf" page using the pdf template under a download folder you created earlier. 6. Give it the title and in the name field add ".pdf" to the end (could also leave as is) Template PHP file for the pdf files 1. Create the template file pdf.php in your /site/templates folder 2. add the following code: <?php // pdf.php if($page->pdf){ wireSendFile($page->pdf->filename); } Done. To see the options you have with PW's wireSendFile() you can also overwrite defaults <?php // pdf.php if($page->pdf){ $options = array( // boolean: halt program execution after file send 'exit' => true, // boolean|null: whether file should force download (null=let content-type header decide) 'forceDownload' => false, // string: filename you want the download to show on the user's computer, or blank to use existing. 'downloadFilename' => '', ); wireSendFile($page->pdf->filename, $options); } Simple and powerful isn't it? Try it out. Some thoughts advanced Create as many file types as you like. It might also be possible to use one "filedownload" template that isn't restricted to one field type but evaluate it when being output using $page->file->ext, or save the file extension to the page name after uploading using a hook. One last thing. You can add other meta fields or preview images to the template and use those to create lists or detail pages. It's all open to goodness. Again all without "coding" and third-party modules. Further more you can use the excellent TemplateDecorator to add icons per template and have a nice pdf icon for those pages. This as a base one could also easily create a simple admin page for mass uploading files in a simple manner, and create the pages for the files automaticly. ImagesManager work in the same way. Cheers

I have HootSuite running for social media management. One thing I like to do is have separate streams running for various CMS I have an interest in. This means I can quickly see all posts mentioning CMS A, CMS B, CMS C etc in a dedicated stream. Makes it easy to follow community topics and product developments etc. But it also makes it easy to gauge social media chatter in relation to a CMS. One thing I've always noticed is how few mentions and tweets PW gets compared to other CMS. IMHO we have a very active and enthusiastic community (as evident from the forums) but a relatively quiet community when it comes to Twitter and Facebook. I'm guilty of this myself but the same thing occurs to me every time I see those three social media streams lined up side by side. Why is it that users of CMS B and CMS A are so vocal on twitter, google plus etc and quick to promote their CMS when PW gets a mention or re-tweet only every second of third day? Incidentally, the 2 other CMS I follow are not huge platforms where you'd naturally expect thousands of tweets a day in comparison to ProcessWire. Anyway, the above occurred to me again after reading Ryan's roadmap post where there was specific mention of This was followed by mention of : curiously there was no mention of social media. Is there an unintentional prejudice against Twitter, GooglePlus and Facebook etc that we're not aware of? Ok, it's an odd question but I thought it'd be worth a check. ProcessWire is growing in userbase, the forums are attracting new members weekly, the CMS itself is a work of art, we have wonderful blog updates on a weekly basis and we have Teppo's PW Weekly too. That energy and excitement seems to ripple out so far and then stop when it reaches an invisible social media force field...

Here's my first serious attempt at a PW module. I have the need that pages shouldn't be "published" in all languages at once, so I've put together a PageLangPublish module. It adds both buttons for publishing/unpublishing of each language to the page tree and status icons (from image fields added to each page in admin/languages) next to the page title in the tree. You can find the module at github under https://github.com/BitPoet/PageLangPublish I've probably done a lot of things quite awkwardly (even incorrectly) there, so I'd be grateful for any pointers and ideas. The module also adds a hookable isLanguageViewable method to the Page class. Usage example: $topnav = array(); foreach($homepage->children as $item) { if( $item->isLanguageViewable($user->language) ) { $topnav[] = "<a class='topnav' href='{$item->url}'>{$item->title}</a>"; } } echo implode(" | ", $topnav); Here's a screenshot:

I created a hook on ProcessPageEdit::processSaveRedirect to redirect to an external website when the edit page is saved under certain circumstances. This is working great for regular edit pages, but doesn't work for modal pages (i.e. lister). Is there a way to initiate a redirect from the modal window?

Not sure if there are more detailed documents, for now I found this https://processwire.com/blog/posts/processwire-3.0-alpha-2-and-2.6.22-rc1/#compiled-template-files

Soma, i never thank you for your accurate reply. The SQL query makes a perfect job. Thanks!

Hi @flydev Welcome to ProcessWire and the forums and thanks for using Blog. If all you want is to show the titles, there's no need to call the module itself. The posts are normal ProcessWire pages, so adapting your code like below should work. <div class="col-sm-4"> <h3>Recents</h3> <?php $out ='<ul>'; //$blog = $modules->get('MarkupBlog');// no need for this line //$posts = $pages->find("template=blog-post, limit=5, sort=-blog_date");// if you want to sort by date $posts = $pages->find("template=blog-post, limit=5"); foreach ($posts as $post) { //var_dump($post); $out .= '<li><a href="' . $post->url . '">' . $post->title . '</a></li>'; } $out .= '</ul>'; echo $out; ?> </div>

I sometimes tweet the official @ handle but was wondering if it would be better to tweet hashtag instead..? #processwire

@rick: In this case we are back to square one, that is "processwire shouldn't be implying endorsement of 'anything else'" which is the current state we are in Without an easy to use ("shape it to your needs") frontend "framework", you cannot guide beginners/non-developers in tweaking the profile they use. In this case, we are talking about bloggers, small companies, etc, who need a reliable, easy to maintain CMS (ProcessWire) and want to tweak the frontend a little bit, but they do not want to "develop" anything. They just need useful tips and code snippets with step-by-step instructions on how and where to apply them. I know, this is not the basic idea behind ProcessWire, but the topic here is "PW Site Profiles are like WP Themes?", and we cannot solve it without anything pre-build for the frontend.

The issue I have with providing joopalpress, out-of-the box, pre-configured solutions, is processwire shouldn't be implying endorsement of any framework or component that is not processwire itself. By including any of those in a default installation, or as an add-on, would degrade processwire to the level of the joopalpresses. The primary strength is processwire is non-destructive and non-limiting with a developer's creations. What I think might be a solution, is to create a sub-forum under getting started where we can provide topics on setting up processwire with whatever framework (or other add-on) as a guide for new users, and even for seasoned developers to look at. We could also demonstrate how to swap site profiles. I think it would be advantageous to show new users how easy it is to utilize these various components with processwire. But putting all the combinations into an install would not be my first choice.

Ok thank you for stepping in on this and for your explanation. I guess I have to play around with both conditional logic and wireRenderFile in a template file to see the difference between them in dynamic use.

This is just my personal opinion, but I hate social media. Actually, I find it annoying to be constantly interrupted with tweets, or other messages, while working. And when I'm not working (read playing golf) the last thing I'm concerned about at that time is an update. I also try to keep things centrally located so that I don't have to go lookin' at other places to get my news or information. As it is now, we search both the forum and github for information regarding a topic. I think it would become a maintenance issue to add more avenues. Don't get me wrong, I'm not against using these tools to better the publicity, I'm just sayin' I personally don't use them.

Actually, I didn't completely describe my concept, so it looks like it is about replacing _main.php, but it is something else. What I want to achieve is a tree/recursive like template file render method, which starts with $layout = wireRenderFile("layout/home.inc.php") and this $layout is echoed out in _main.php which I - normally - do not want to change since _main.php contains the head(er) and the footer of the site (in case of a "classic" page layout), however each page should be configurable to use its own "layout". The actual "layout file" also contains wireRenderFile() call(s), to render reusable parts of the site. So the rendering process starts with echo $layout and continues down the "partial file tree structure" by using more wireRenderFile() calls to "include" the required template file partials. It is just like using simple php includes with direct output. So it's a rather simple concept, but it can be extended by using a few more variables besides $layout to solve problems like not loading not needed resources into a given page (like not loading jQuery on pages where it is not needed, etc...) I hope I was able to explain it clearly this time.

For question #1, there's a less complicated way to go about it. Create a Page field called "Favorites" (or "Subscriptions"). Templates allowed for this field should be: episode, series, and whatever else can be favorited. Add this Favorites field to the User template. Program the feature as needed. For question #2, the approach you outlined is pretty correct and the ProcessWire way of doing things (or you could also use Options Fieldtype, but I don't prefer it). I personally call it "Options" instead of "Tools" and pluralize the option types (Languages instead of Language, Durations instead of Duration). Then create Page fields as necessary.

Avoid repeaters. One problem / limitation with them is that each repeated item is of the same template. If you have a page with many sections that each have a different template, then repeaters are not the tool. Instead, use a page select (page or pagetable). The limitations of repeaters have been discussed throughout the forum. Given the advances of PW in the last few years, I would consider the Repeater fieldtype's use case to be diminished.

(Sorry, couldn't resist. English is such a wonderful language, don't you think?)

Depending on the setup of the server as subdomain might need another rewritebase in the .htaccess file.

cool i think you have a typo in your first codeblock?

A great tutorial mr @gebeer, Also I recommend using postman for simple endpoint testing https://www.getpostman.com/ http://raml.org/ for api documentation, definition and simple mockups And for testing apis nothing beats Behat http://docs.behat.org/en/v2.5/ http://shashikantjagtap.net/restful-api-testing-behat-guzzle/ https://github.com/Shashikant86/RESTful-Behat

Got it, it was echo $page->render()

Hi guys, Been "kicking the tyres" on some UI tweaks to the PW image fields and modal windows. Many of these are in-progress designs and to be straight, none of the designs are entirely resolved. At this stage, I thought I'd throw them up (poor choice of words!) and maybe someone can take them further or offer some fresh eyes. I'm not a developer so making these a reality is impossible for me. They're flat designs. Why? PW is an amazing experience for editors. It's just so elegant and beautifully realised (especially with Reno Theme) that often, my training sessions with clients are very brief. One area which does cause friction though has always been concerned images, image fields and image modals. Especially with the latest image modules, I think a lot of inconsistency has crept into the UI. Hopefully these designs can help improve things a bit. A tiny part of the design work is influenced by a similar idea I had for MODX but which never progressed. 1A. Current Image Modal Editor has clicked 'Add image' icon in CK editor. Issues: I believe the Upload Image button can be better placed. It's not clear to users that they have a choice of two actions (Select an Image OR Upload one) To help solve this, I thought we could: Place available images under a Choose tab Create another tab titled Upload Rename modal to just Image (from Select Image) tweak slightly the Images on page path to be less prominent The following image illustrates the result. Clicking the Upload tab would result in: In the above image I've created toggle-able accordians for Drag and Drop and Manual upload. This follows closely the UI an editor is presented with when choosing Insert Link within CK Editor. IE Link to URL, Select Page and Select File and the extra Attributes tab. So overall, it's more consistent. 1B. Alternative to above - combined Select and Drag/Drop I thought it might be worth exploring what modal would look like with no tabs and a single UI for both Selecting an image and Drag/Dropping. 1C. The Image field I then moved onto looking at the Image field in PW. So currently it looks like this (below) for a simple image field called Image Gallery. So although the current Image field works great, I wondered if there was a way to simplify it by Making the drag/drop more visual and obvious Moving the Choose Files button and removing the No file chosen text and the file types allowed Here's the result. Admittedly, this treatment adds more height to the overall field. Here's how it looks when images are uploading (slightly smaller plus icon and "drag and drop..." text. To be honest, I can't recall what other changes I made there! And here's a proposed layout for when there are multiple images. This includes image titles grid layout mouse-over for edit and delete options/buttons 2. Cropping Next thing I looked at was cropping. Native cropping introduced recently is one of my clients favourite features and time-savers and I wondered if things could be improved a little. So heres the current layout (this may have changed further recently) And here's my proposal. Changes are: Width, height and X and Y fields are moved below the image Apply and Cancel placed bottom right of the image Save Crop should be titled Apply. I think that's less confusing as in some instances there are so many Save options Save and Replace should be greyed out further In addition to this, I thought it'd be neat if we had the free-form cropping function introduced by Ryan combined with some kind of list of pre-sets (displayed on right hand side). Forgive the croptions label (Crop + Options pun - I was tired!) The benfit of this I think is that Modules such as CoppableImage and native Crop would be unified in a single UI. Presets (on right) could be a few out-of-the-box presets which come natively. Croptions houses any crop ratios defined in image modules. if CopppableImage isn't installed, they just don't display.. That's it. I wish I'd more time to work on this but it's at the stage where it's ready for some initial thoughts. Hope you guys like.

This post has had an inexplicable surge of Likes over the past few weeks so there seems to be quite a bit of interest in this 7 months later. I've been unable to follow these concepts up with the time they deserve but those interested in an mage field tidy up can see Toms own beautiful work mentioned on the Dec 18 blog post. Furthermore, Ryan mentioned in today's Roadmap blog post that these (Tom's) designs are already being worked on by LostKobrakai. Exciting stuff!

** replaced with this: https://processwire.com/talk/topic/11817-module-adminhelp/ ** This is a new module, work in progress/alpha (not for use on live site): [github link deleted] AdminDocsTab module for ProcessWire Processwire helper modules for managing site documentation. Instructions This is a helper module which expects you to have already setup a hidden part of your page tree to establish your documentation, using any template (e.g. 'docs') and a body field (ckeditor). The docs template does not need to have an output template, as the module will only echo the body field inside the admin. In addition this 'docs' template will require a template select field (separate module: FieldtypeTemplates) which should be named template_select. Once you have setup your docs template, template_select field and some docs pages, you should install the AdminDocsTab module, then select the template(s) to show the docs on, as well as the root page of your docs. At this point the 'Docs' tab should show up for the relevant template (as specified in the Doc), and show the docs that have that template specified. To have a global docs overview page (e.g. 'Docs'), which renders all of the docs in an accordion view, you can install the ProcessDocsView module, which will setup a page to view the docs (under Setup).

Well, I do not even know what I am doing in front of the screen at this time..., but I must have drunk too much champagne anyway... so a little bit of ProcessWire template file building cannot hurt to much I suppose... So, where was I Sorry, it is off topic I know, but I wanted to reply to Ryan's suggestion, that calls this function in question as "wireTemplateFile()". When was it renamed to "wireRenderFile"? It is still called as "wireTemplateFile" in the comments, where it should be corrected I suppose. Oh, and in this changelog: https://processwire.com/blog/posts/processwire-2.5-changelog/ Other than that, I came up whit this version of the delayed output as my preferred one: in _main.php (which I renamed to _page.php) I have <?php echo $layout; ?> between the "header" and the "footer", and the actual template files do only this: $layout = wireRenderFile("layout/home.inc.php"); that is, they render the associated "alternative syntax style template partials", so this is similar to the simple direct output, but with the benefits of the delayed output. To much champagne in my brain, told you, sorry for this post, and HAPPY 2016 everyone!

I will carry on researching this (will check out blog module), this is/will be my first real module of any consequence... lot of stuff to learn, thanks for the help! Module Under Construction: https://processwire.com/talk/topic/11803-admindocstab/

Hi jmartsch, Unfortunately, I haven't given this much attention of late, but will be getting back into it in January. At the moment, I'm busy moving both modules over to their new homes on Github, and publishing the new documentation site for Jumplinks. Hoping to get the forms module done soon - sorry for the delay.

The resource files with the same name as the module should be loaded automatically and even be cachebusted. But there might be rare edgecases, where you'd need to include them manually because processwire might load them to late or something. I'd only do that if the need arises.

For a site with `https` it doesn't make a difference: http://isit.pw/?url=kf-interactive.com - Yup http://isit.pw/?url=www.kf-interactive.com - Yup http://isit.pw/?url=http://www.kf-interactive.com - Yup http://isit.pw/?url=https://www.kf-interactive.com - Yup But for a site without `https` it does make a difference: http://isit.pw/?url=www.schau-platz-wittenberg.de - Yup http://isit.pw/?url=schau-platz-wittenberg.de - Nope

For your "typical example" of "the contact info in footer area", you can, for example, just: create a Contact information page (that is hidden), insert <?=$pages->get('/contact-info/')->body?> wherever you want in _foot.php, or elsewhere. That's it. The content editor edits the body field of the Contact information page. There's no need for a template for this page normally. If you define (in _init.php, for example): $contact_info = $pages->get('/contact-info/')->body, you just have to use $contact_info wherever you want. It could be anything of course. Not just a CKEditor textarea body field.

I'm using Nette Forms standalone for forms, it is very powerful but easy to setup: http://doc.nette.org/en/2.3/forms#toc-nette-forms-standalone Cool thing is that with Live Form Validation javascript it provides JS validation too: https://gist.github.com/Robyer/7948399 It is also capable to handle conditional fields, so for example show an input field only if you select an item in another select box, etc. And all this stuff works with live js validation, so you have to set rules once and both backend and frontend validation are done. 99% of the time the default form renderer is enough, but you can fine-control your forms if you need to: http://doc.nette.org/en/2.3/forms#toc-defaultformrenderer http://doc.nette.org/en/2.3/forms#toc-manual-rendering You can use Bootstrap style too: http://doc.nette.org/en/2.3/forms#toc-bootstrap-support For example, I use it with UIkit: <?php // load Nette Forms require_once(__DIR__ . '/../../../vendor/autoload.php'); // make a new Form instance $form = new Nette\Forms\Form; // optional tweaks $form->setAction($page->url); //$form->setMethod('GET'); // set "novalidate" and classes $form->getElementPrototype()->novalidate = 'novalidate'; $form->getElementPrototype()->setClass('uk-form uk-form-horizontal'); // set how form is rendered $renderer = $form->getRenderer(); $renderer->wrappers['controls']['container'] = 'div'; $renderer->wrappers['pair']['container'] = 'div class="uk-form-row"'; $renderer->wrappers['label']['container'] = 'div class="uk-form-label"'; $renderer->wrappers['control']['container'] = 'div class="uk-form-controls"'; // add fields $form->addText('name', 'Name:', 30) // ->setAttribute('autofocus') ->setRequired("Required field") ->addRule($form::MIN_LENGTH, "Please add at least %d characters", 3); // display form echo $form; ?> Processing form is another issue, you can start like this: if ($form->isSuccess()) { // get submitted values (true: array format, false: object) $values = $form->getValues(true); $sender_name = $values['name']; $sender_email = $values['email']; // ... // redirect // $session->redirect($success_page); // exit; }

Thanks, Horst! I've created my forum account last year. The reason: FormBuilder, ProFields, ProCache So I also think there are many... many (!) other out there

Ok since some different things are up to the client now - but the main work was done i'd like to show my first work with PW and give some feedback and kind words about the workflow. First i've to say thank you - ryan for this awesome diamant of code and all members here that treat every other with respect and patience! Domain is not open until some bureaucratic things are ready. http://gs-altfraunhofen.de/ This was no big project but not really easy, since there was no real basic stuff to start with, and the existing things (like a strange version of the logo you could see now) are done by some teachers and changing them was a little hot political thing....hot pavement! For such a little project with less budget i give the easy http://purecss.io/ a try and work with that. Tried to give the website some individual notes, but stay with many given elements by the small CSS Framework (buttons, forms) to save time/budget for the client. Here some screenshots of the page and changing on responsive: Desktop Mobile Backend Some special modules that i used: FieldtypeEvents (with some changes) FormTemplateProcessor (with adding some spamdetection, hidden honeypot and a "leave blanc" field) MarkupSimpleNavigation PageListImageLabel ProcessAdminCustomPages VersionControl Some special adjustments and using of some modules: FormTemplateProcessor Get a Form from given fields in a backend template and save them as pages and/or send them to a mailadress....easy task with the FormTemplateProcessor. For some spamdetection a added a hidden field as a honeypot and a questfield to leave blanc to check against bots. //Changes for better Spamprotection with a hidden additional field as a honeypot // create a text input a hide it via CSS .Inputfield_name2 display:none - see CSS example on the end of this module $field = $this->modules->get("InputfieldText"); $field->label = "Name2"; $field->attr('id+name','name2'); $field->required = 0; $form->add($field); // append the field to the form //end changes /**and at the end**/ //Create a field quest in the form template with heading like "please show us youre human an leave this blanc" //Set the Spamfilter and check if field quest or spam are blank! $questfield = $this->input->post->quest; $spamfield = $this->input->post->name2; if(empty($spamfield) && empty($questfield)) { echo "<h3>Ihre Email wurde gesendet!</h3>"; // see if any errors occurred if(count($form->getErrors())) { // re-render the form, it will include the error messages $out .= $form->render(); } else { // successful form submission, so populate the new page with the new values. foreach($form as $field) { $this->contact->set($field->name, $field->value); } if($this->email) $this->sendEmail($form); //if($this->parent) $this->savePage($form); $out .= $this->successMessage; } return $out; } else { echo "<h3>Es ist ein Fehler aufgetreten - Sie haben das letzte Feld ausgefüllt bitte versuchen Sie es erneut!</h3>"; } //end changes Frontend Backend ProcessAdminCustomPages This is a real great module for custom made admin pages. You simple add a page to the admin setup the process and add a templatefile in your site folder! Admin stuff made easy even for non devs! example code from the imageoverview (CutomAdminPage Template): <?php // Bilderübersicht Custom Admin Page ?> <style type="text/css" media="screen"> /** * larget magnific popup */ .mfp-iframe-holder .mfp-content { max-width: 1200px!important; } </style> <script type="text/javascript"> $(document).ajaxComplete(function() { //add trigger class and modal setup $('.PageListActionEdit a').each(function(){ $(this).addClass("lb-edit").attr("href",$(this).attr('href')+"&modal=1"); }); $('.PageListActionNew a').each(function(){ $(this).addClass("lb-edit").attr("href",$(this).attr('href')+"&modal=1"); }); //setup lightbox $('.lb-edit').magnificPopup({ type: 'iframe', disableOn: 0 }); }); </script> <?php //get Magnific css and js $this->modules->get('JqueryMagnific'); //render PageListtree with setting the parent page $formImages = $this->modules->get('InputfieldForm'); // prep the form $wrapperImages = new InputfieldWrapper; // a wrapper $wrapperImages->attr('value', '<h2>Bilder</h2>'); $i = $this->modules->get('ProcessPageList'); // get the pagelist process $i->set('id', 1015); // setting the parent page $pageTreeImages = new InputfieldMarkup; // the placeholder $pageTreeImages->value = $i->execute(); // fill the InputfieldMarkup form field... $wrapperImages->add($pageTreeImages); // put inside the wrapper... $formImages->append($wrapperImages); // append the wrapper echo $formImages->render(); And as result i've a adminpage just with the imagetree. For this kind of websites where i've very less images and use it on different pages - i'd like to have a mediacenter - and this is the way i get it work. Using the image approach from somas imagemanger module: https://processwire.com/talk/topic/3219-images-manager-beta/ But only the setup for the templates (single image fields and cats) - and have an easy administration like the whole site in a PW style. One bad thing with a own usage of the ProcessPageList - while editing after save you will be redirected to the "real pagetree" not the custom one! So no problem, it would be much better to use a kinda a modal editing on this special content - no problem all there just to find and use. (Combined it with the PageListImageLabel to show some thumbs in the pagetree) For the images first i thought i change the Tree where in the Wysiwyg the image is choosen to insert - this works so far mor details here: https://processwire.com/talk/topic/7439-processpageeditimageselect-hook-and-change-default-page/ But then i decided to don't let the users handle images in the wysiwyg and added a fieldset TAB for images and populate them if the users choose some on the right place on every page. So i've with a Pageselect field (parent page is the image-root) a simple "click on the images to show gallery" possible on every page: Here some screens on the backend of the custom admin page for the images with the template from above: Did the same for the documents section where i again use soma setup for files as pages: https://processwire.com/talk/topic/4602-flexible-downloads-using-pages/ This is a real great tutorial - you can expand all you need for such documents for eg. a counter is simple as easy PHP: 1. Setup a single file field, a counter integer field and a template for the kind of files you are using f.e. doc.php, docx.php, pdf.php and now use such a template file <?php /** * doc.php */ if($page->doc){ $page->of(false); $page->counter += 1; $page->save(array("quiet" => true)); $page->of(true); wireSendFile($page->doc->filename, $options); } Benefits from files as pages are real SEO Links on documents and images like: http://gs-altfraunhofen.de/dokumente/morgenbetreuung.doc/ some tweaks on the contact-page and some others in the admin.php to get them always in the state i want them i've some code like this: /** * setup choosen templates to hidden - equal witch setting the user takes */ $pages->addHook('saveReady', null, 'makePageHidden'); function makePageHidden(HookEvent $event) { $page = $event->arguments(0); if($page->template != 'doc' && $page->template != 'docx' && $page->template != 'pdf' && $page->template != 'image-category' && $page->template != 'image' && $page->template != 'contact_form') return; // replace 'category-site' with your template name if(!$page->is(Page::statusHidden)) $page->addStatus(Page::statusHidden); } For me like wrote i'm not a developer, not a real good coder, but i like the way that PW (and this awesome community) teach me in the right direction and let me be free in the way to solve my challenges! So closing the circle and say again thank you to all that read this and contribute to PW and this forum! Have fun - best regards mr-fan

Your hook and method has a lot wrong. If this all would work, then you would hook into Inputfield::render() and not Inputfield::renderValue(); And a hook to do what you wanted would look more like this: function hookAppendClassName($event) { $className = " mygrid"; $classes_array = $event->object->getParent()->getClasses(); $classes_array = array_merge($classes_array, array('item' => $classes_array['item']." ".$className)); $event->object->getParent()->setClasses($classes_array); } But this is not possible. When a inputfield is rendered in the inputfieldwrapper, the classes and markup is already set and you can not overwrite it at that moment in time. I also was looking into this and by chance I found a line of code in latest dev, that seems to be added recently. InputfieldWrapper rendering method looks for a $inputfield->wrapClass, I didn't know was there. So you can now simply do this: $field = $modules->InputfieldText; $field->label = "Name"; $field->wrapClass = "mysuperlol-col1--wonder__toootooo"; ...

Don't Show API Form Labels (If I may add this here for the sake of completeness.) I have been looking for a way to leave the label out of the markup that does not involve recreating a module (a silly thing to do). The solution we have been using up until this point was a blank label. (Resulting in unnecessary markup and a negative margin.) However curiosity took me to the Inputfield module. Hey great job on these fields BTW. Reading the file I came across these options. const skipLabelNo = false; // don't skip the label at all (default) const skipLabelFor = true; // don't use a 'for' attribute with the <label> const skipLabelHeader = 2; // don't use a ui-widget-header label at all const skipLabelBlank = 4; // skip the label only when blank // wire/core/Inputfield.php Found in: in Inputfield.php The best solution I found to use this in a form builder. (I would like to credit this to somma's comment on checkbox-other-text-in-header-than-label-text) //controller.php $submit = $modules->get("InputfieldSubmit"); $submit->skipLabel = Inputfield::skipLabelBlank; //HERE IS THE SOLUTION! $submit->attr("value","SUBMIT"); $submit->attr("id+name","submit"); $submit->attr("class","button"); $form->append($form_submit); Thank you Somma! Thank you Ryan!

If you are planning to build a template for pages that will be viewed on is own, as well as rendered from other templates try this: if ($page->url == $_SERVER["REQUEST_URI"]) include("./head.inc"); // template code if ($page->url == $_SERVER["REQUEST_URI"]) include("./foot.inc"); The head and the foot will be included only if the page is on it's own url.