Leaderboard

Hi i wanted to share my website http://carbatteryassist.co.uk that i built for my offline business , I built it first with wordpress, then try'd Concrete 5 still wasn't happy so i went with processwire and foundation 5. When i'm not out fitting im learning all about webdesign, for my own site and to help others. There's still a long way to go but wanted to get my first processwire creation out there

Hi! Oh, here is something bigger than I have made before: autosystem.ru Was used: PW (latest dev) Foundation 5 for grid layout (but not for long, want to rewrite grids with Susy — it is awesome). ProCache Markdown HannaCode Fredi Map Maker Pageimage Sizer Imagick and great help of all of you Thanks for any suggestions and kind words

Hi kongondo, Thanks for the quick reply and the welcome. I had actually already read the topic that you mention, and this is what prompted my need: I would like to save a "stock" field for each product, but this field would have to be calculated each time a stock movement is saved, and calculating this field is precisely what takes so much time. In the meantime, I continued looking into the problem, and I think that I came up with a solution with the following module: class PagesSum extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Pages Sum', 'version' => 1, 'summary' => 'Adds a $pages->sum($selectorString, $fieldName) function to sum the value of a specific field over a list of pages selected by a selector string.', 'singular' => true, 'autoload' => true ); } public function init() { $this->addHook('Pages::sum', $this, 'sum'); } public function sum($event) { $selectorString = $event->arguments(0); $fieldName = $event->arguments(1); // Find all the pages associated with the selector string $pageFinder = new PageFinder(); $idQuery = $pageFinder->findIDs(new Selectors($selectorString), array('returnQuery' => true)); $idQuery->set('orderby', array()); $idQuery->set('groupby', array()); $idQuery->set('limit', array()); $stmt = $idQuery->execute(); $idArray = $stmt->fetchAll(PDO::FETCH_COLUMN); // If no pages were found, return 0 if (count($idArray) == 0) { $event->return = 0; return; } $idString = implode(',', $idArray); // Get the table name for the given field name $field = $this->fields->get($fieldName); // If no field with this name is found, return 0; if (!$field) { $event->return = 0; return; } $tableName = $field->getTable(); // Run the SUM query $sumQuery = new DatabaseQuerySelect(); $sumQuery->select("SUM(data)"); $sumQuery->from($tableName); $sumQuery->where("pages_id IN ($idString)"); $stmt2 = $sumQuery->execute(); list($total) = $stmt2->fetch(PDO::FETCH_NUM); $event->return = $total; } } In my tests, it is about 60 times quicker to calculate the sum with the function $pages->sum($selectorString, $fieldName) than looping over the pages (for about 12000 pages). I would appreciate any feedback, in case there are any other optimizations to be achieved, or any errors I haven't thought about. And I hope that this might maybe be useful to others too!

In your function you are just asking for the total number. If you need only this thats easy done. $pages->get('name=posts')->numChildren; more options http://cheatsheet.processwire.com/page/built-in-fields-reference/page-numchildren/

Whether or not you change your mind, the issue you had is actually well explained in that puke you mentioned: you're trying to use method count() of something that isn't an object, and thus can't have its own methods. This non-object in your case is the $pages, used in a function. The reason for this is that in functions and class methods you have to use API vars with the wire() function -- wire('page'), wire('pages'), wire('session'), etc. In other words, your code should work just fine if you just replace $pages with wire('pages') You're right in that ProcessWire has built-in pagination support: https://processwire.com/api/modules/markup-pager-nav/.

Image Animated GIF v 2.0.2 Module for PW 2.5 stable or newer, but is obsolete for PW Versions greater then 3.0.89 (... read more ...) This module helps with resizing and cropping of animated GIFs when using the GD-Library. The GD-Library does not support this. This module is completely based upon the fantastic work of László Zsidi (http://www.gifs.hu/, builts the initial classes) xurei (https://github.com/xurei/GIFDecoder_optimized, enhanced the classes) I have ported it to a PW module and it works with core imagefields, together with Pia and with CropImagefields that uses the new naming scheme since PW 2.5. ------------------------------------------------------------------------------------------------------------------------------------------ read more in this post about the rewrite from version 1.0.0 to version 2.0.0 ------------------------------------------------------------------------------------------------------------------------------------------ You can find it in the modules directory: https://modules.processwire.com/modules/image-animated-gif/ and on Github: https://github.com/horst-n/ImageAnimatedGif ------ A preview can be found here

@kixe, have you seen this thread already: https://processwire.com/talk/topic/741-a-guideline-for-module-naming/? That's a good start, especially when it comes to "reserved module names", though for something like your module it doesn't exactly give any foolproof answers.

Try $pages->find('parent=/widgets/')->filter('id=1020|1069|1070|1071|1072|1073|1074|1075|1076')->getRandom(); Might work. <edit>Removed non-working guess to avoid confusion in future.</edit>

For security reasons, you can't directly access files like that within the the PW templates directory (as well as others). Hmm...I always thought it's only PHP files that this restriction applies to but possibly HTML files as well? Somebody more knowledgeable will clarify Possible workarounds if restriction also applies to HTML files: use an include in a template file place the file outside PW directories and reference it from those locations

@toothpaste - are you looking for something like any of these examples? I could post code for these if that helps: using processwire, search function - page reloads on select (this is great since you can bookmark results) http://www.ohmspeaker.com/speaker-finder/ using jQueryDataTables - no page reload, but also fast filterable results with many dropdowns: http://katonahartcenter.com/pages/daily-schedule/

I absolutely get your point, Soma. I’ve always been a trial-and-error kind of coder, so I tried a lot, built a lot of stuff the way I thought was right. I hated how bad my code was structured and how hard it was to maintain. So I experimented with ways to separate things, tried approaches like your “delegate” one but didn’t really arrive at a point of happiness. As I said I have been experimenting with other languages and frameworks like Ember, Rails etc. and I really fell in love with the burden of defining a meaningful and comprehensible structure being taken off me. Of course, the thing that brought me to PW was its freedom. But for me as a designer it was especially the freedom of how to build templates (as data containers) and how to present them easiy with PWs API at hand in your template files. But as soon as you want your PW site to do more than render web pages it (at least in my semi-semi-pro-dev experience) gets messy pretty fast when you try to wire things up to make a page do more than one thing. So I really think it’s justifiable to use PWs modular base to build a MVCish layer upon it. Especially when you think of the fact that native page rendering has been a module itself from the start. Of course it’s not ideal to have a dozen of concepts around. I’ve kept an eye on earlier modules/concepts going in a similar direction but they mostly just dealt with a certain part of my issue. So I started experimenting (again) to create kind of a proof of concept and I wanted to share this with the community. If there is a real MVCish approach that is/will be supported by PW Core Team I’d be more than happy to support it. Did I miss something here?

Often times, creating a side project is first and foremost scratching your own itch Or to start differently: Currently, I'm developing a site where I need CKeditor (and later jQueryUI Datepicker) outside of the admin, in frontend. I searched Google and the forums and found an approach to follow - but during the research the site laravel-recipes.com came into my mind (since I'm currently also looking into this framework). It's content consists of small, spot-on bits of information, for example: http://laravel-recipes.com/recipes/269 Just to think out loudly here, wouldn't it be nice to have a ProcessWire counterpart of such a site? processwire-recipes.com for example? Target group: Developers, from beginner to advanced Difference to these forums: Stripping the discussion part, concentrating on the info; and if done properly: bypassing the mediocre forum search, better tagging Difference to the official tutorial section: Focusing on not creating a whole site, but modular parts of it. Single solutions. For example: First child redirects (shameless plug, but this is the format of information pieces I'm having in mind) Difference to the API documentation: Situation-based ("I need this and that") instead of architecture-based Laravel.io (forum), laravel.com (official, and doc) and laravel-recipies.com possibly prove that these type of sites can coexist in a framework ecosystem, so I guess a recipes site would not cannibalize this forum here nor the doc section. A recipe site like this would live and die with its content, of course. I would be ready to share all the small pieces of information I encounter that would make a good "recipe". But that alone wouldn't be enough so this project won't survive without contribution of the community. What's your opinion on this? Yea or nay? Update: ...it just took, erm, nearly three months,... but here it is: https://processwire-recipes.com/

Hello there, ProcessWire has been the perfect CMS for me so far but I always missed the Laravel way of doing things when working with PW. Therefore I've built a package that will integrate Laravel into ProcessWire. It's already working out really well and I can imagine a lot of stuff to come in future. Anyways I'm hoping for some peoples support / pull requests / ideas / opinions ... Here's the link: https://github.com/hettiger/larawire Enjoy!

Sup. FieldtypeOpenWeatherMap [GitHub] This module fetches and stores current weather data from the OpenWeatherMap.org service and helps you manage icon markup. To limit requests, OpenWeatherMap.org’s JSON-response is cached in the database and only refreshed once the field is accessed and the cache has a certain age that you define. The fieldtype is sadly not multilingual, but you can configure the language of the weather descriptions OpenWeatherMap.org provides you with. It would not be hard to make the output multilingual by referencing weather codes and translating them with ProcessWire’s built in tools. You install FieldtypeOpenWeatherMap just like any other module, by placing the two files into ProcessWire’s modules directory. Once installed, you want to create a new field of the type OpenWeatherMap and assign it to a template. The template now has a text field that stores a city id. In the field settings, you may configure how and when the data is requested. That is, the requested language, units (eg. °C/°F/K) and the cache duration. The module does not provide you with built in icons or otherwise limits you to predefined markup (which I consider a good thing ). The icon in my example above is courtesy of Alessio Atzeni’s Meteocons (custom free license). To make generating icon markup a little easier, you can configure your own markup snippets in the module configuration: As you can see, in this example I’m using an icon font whose appearance is defined elsewhere in my CSS, but you’re free to put in image urls or just unicode entities or whatever. Rendering it is now quite simple. The following markup would result in something like the image above: <?php $w = $city->weather; $temp = round($w->temperature); ?> <p><?php echo "{$w->renderIcon()} {$w->description} at {$temp} °C"; ?></p> <h2><?php echo $city->title; ?> <span class="ico-rightarrow"></span></h2> <!-- irrelevant line --> The variable $w is now a WeatherData object that exposes the following properties: json //The raw JSON response from OWM timestamp //The time of the request city_id //The city id you entered in the admin sunrise //The time of sunrise sunset //The time of sunset main //The main weather name, e. g. “Rain”, in the configured language description //A slightly longer, more precise description like “occasional rain” iconcode //The internal icon code for this weather temperature //The temperature in the format you requested min_temperature //... max_temperature //… wind_speed //I believe the wind speed is also affected by the unit settings. As well as the method renderIcon(), which you already know. If you access a WeatherData object as a string, you will get the city id. This is so that the city id will correctly appear in the admin page edit form. I should mention that there is some more information in the JSON, such as wind direction. The module also exposes the method multiRequest(PageArray $pages, $fieldname). If you want to fetch data for a bunch of pages at the same time, you may want to use that so as to reduce unnecessary requests to the service. I haven’t really used this yet, so consider it experimental, I guess. As of now, this also disregards the cache freshness. If you’re still reading, there’s a chance you might be interested in using this. Allow me to clarify that right now there is no support for forecasts or historical data (yet?). Sorry :> Here’s the GitHub link: FieldtypeOpenWeatherMap.

Hello, I'm trying to import some polymer elements, but for some reason I get a 403 this is the code <link rel="import" href="<? echo $config->urls->templates ?>bower_components/paper-input/paper-input.html" /> Is there a workaround? Thanks!

Was just reminded of this module as I stumbled upon the Wild Beasts x Mattis Dovier GIF-novel. Also read an interview where the artist (at least I think it was him..) declared that GIF is making a come-back, or something. Can't really disagree after seeing the GIF-novel

Introducing PVC PvcCore: https://github.com/oliverwehn/PvcCore/ PvcRendererTwig: https://github.com/oliverwehn/PvcRendererTwig/ (coming soon) PvcGenerator: https://github.com/oliverwehn/PvcGenerator/ (coming soon) Each time I’ve built a ProcessWire page I’ve struggled with organizing (and separating) code, markup and stuff. Playing around with frameworks (backend as well as frontend) like Rails, Ember and stuff I really liked having a given structure, knowing where to put what piece of code. Therefor I started working on a MVCish way to deal with templates in PW that considers the $page object kind of the data/model layer and adds View and Controller upon it. First by just catching everything via a small processor file added to all PW templates as altFilename. I’ve digged a bit deeper since then and hooked into the native rendering process, have been refactoring my code base more than a dozen times. Now I got a first version that seem to work and I’d love some of you guys to try it out! PVC (instead of MVC) stands for Page-View-Controller, as it considers PW’s $page var the model/data layer. I’m still working on the README.md on GitHub to document the basics. So have a look for more detailed infos there. I’ll give you a short overview here: Code separation: PVC introduces views and controllers to your PW templates as well as multiple action templates. Controllers, as most of you already know, keep all the business logic. Controllers execute actions wired to routes (urlSegment patterns). Even routes with dynamic segements (e.g. /edit/:id/) can be defined and assigned to an action, providing input through $this->input->route. Values can be set on the controller to be accessable in your templates later on. It’s also possible to set dynamic values as closures to be calculated (e.g. using field values of the current page) on render. Also controllers allow you to set layouts, styles and scripts to be available in your layout or template. Logic can be shared through inheritance between controllers. Views introduce view helpers. Helpers are functions that are made available to you (only) within your template context. There are predefined ones like embed(), snippet(), styles() or scripts(). But you can implement your own helpers easily and share them among your view classes through inheritance. Action templates contain the actual markup. Every action defined in a controller uses its own template. So the same page can display content accordingly to the action that was addressed via urlSegments/route. Within templates you can access all field values and values set on your controller like globals (e.g. <?=$title?>). Modular renderers: PVC implements rendering through separate renderer modules. PvcCore comes with PvcRendererNative that gives you template syntax the good ol’ PW/PHP way. A Twig renderer is in the making. And maybe you want to build your own renderer for the template syntax of your choice? I consider the module an early Beta version. So make sure to try it within a save environment! Would love to get some feedback (and error reports). I’m no professional developer, so code quality may suck here and there. So I’m glad for inputs on that, too. Also there is some old stuff in there yet, I still have to get rid of.

This is the bit in .htaccess that blocks access to files in the templates directory: # Block access to any PHP or markup files in /site/templates/ RewriteCond %{REQUEST_URI} (^|/)(site|site-[^/]+)/templates($|/|/.*\.(php|html?|tpl|inc))$ [OR] Which is why css, js etc work, but php, html, tpl, inc etc don't.

Looking really nice. And the "powered by processwire" logo in the footer only makes it better)) Formbuilder forms could benefit from some styling, but they are not so easy to customize.

@ESRCH...welcome to the forums. Read you question quickly. Maybe this topic can help? https://processwire.com/talk/topic/5441-kind-of-calculated-field/ It's about creating a hidden field to store a calculated value on the fly. See posts #2 and 3

...yes, and it's faster than count() https://processwire.com/talk/topic/3094-get-first-image-and-title-of-children-pages/?p=30470 https://processwire.com/talk/topic/3094-get-first-image-and-title-of-children-pages/?p=30608

Just wanted to let you guys know that I have submitted a PR to Ryan to fix this issue: https://github.com/ryancramerdesign/ProcessWire/pull/823 Along with this, I wanted to note somewhere (for now here, although I will probably write a PW SVG tutorial sometime soon) that if you want to embed SVGs into CkEditor RTE fields and be able to drag to resize them, you need to add the following to the "Extra Allowed Content" section on the Input tab of the field: img[alt,!src,width,height] This allows the img tags to have width and height attributes, which allows you to resize the image to a fixed number of pixels.

It works. You might haven't configured all correct. This in the init() method public function init() { if($this->config->ajax && $this->input->it == "webservice/"){ if(!$this->input->action) return; $out = array( "it" => $this->input->it, "action" => $this->input->action, "pageid" => $this->input->pageid, ); header('Content-type: application/json'); echo json_encode($out); exit(); } } and then this jquery ajax call work just fine <script> $(function(){ $.ajax({url:'/webservice/', data: {action: 'getPage', pageid: 1001}, method: 'post'}).success(function(data){ console.log("page", data); }); }); Nothing wrong with the PageNotFound as far as I can tell I'm using both approaches

Thanks Oliver for sharing, just I can't really try it out for various reasons. I'm really digging people share their "MVC" approaches, but with this one more, it would be around 5 different ones now around. I'm not sure what to think about the impact on PW new and old users, support etc as it will split and create burdens for one to help someone using x-mvc approach. I have nothing against many ways to setup PW projects and while that's a strength it may even more is a weakness at the same time with its consequences. Really not against you and your approach, it just turns out by chance that I write this here. I'm not sure its worth of discussion. Wouldn't it be better to settle on one "MVC" ish setup that PW maybe even supports, it could help to keep focus on it and maybe even have official docs for it. Often it doesn't help telling a dev hey look there's this this and this but you can also use this and this, but that is not for PW 2.5 while that is only for php 5.5 and the other you can't use if you use multisite and those are not multilanguageable. Hard for me to explain well but I think one get the idea where I'm heading.

This Topic should be marked as answered. Video Tutorial By the way before this option was implemented in core you could enable it by installing my LanguageTranslatorPlus Module which exists since 10/2013.

@fmgujju: I guess I solved it. It was a minor error when passing method calls through my PvcPageProxy class. Grab the latest version from github and give it another try. Thanks for testing. There has been another error in my examples above: In products’ action template for index you have to add ->url at the end of the PW API call within the src attribute of the img tag to make it show the images.

Something to do with the pyramid, as most people think the Giza pyramid has 4 sides, it actually has 8. That's the probable cause of the issue

Hi Richard, If you use the pageField method, then every "tag" creates a page that has a unique name. Example (green-energy, shark-sandwiches, turtle-soup). The autocomplete field presents the user with the page title, so they would select tags like (Green Energy, Shark Sandwiches, Turtle Soup). Same applies for adding new tags. Now you can use UrlSegments to find pages with your multi-word tags because they will be in a format like /domain/tags/green-energy/

@Soma no we don't. @Martijn Geerts Its already done. I updated it and included lock/unlock button too. @kongondo When I started with the module I didn't know about the one from geniestreiche. I startet on the base of Nicos ProcessPageDelete.module. I will not put it in the modules directory. I am open to merge the results with geniestreiche. Sent him a message.

+1 for producing markup-agnostic output. I think most (all?) modules that generate markup should have at least the option of having them output an object rather than specific markup.

@Ivan Gretsky: Thanks for that hint. I opened an issue on github.

@pwired, I don't get your post. @hettiger, thanks for the module, looks interesting, have to look into it at a later point in time though.

Maybe this helps someone. Nerd alert! Currently building a shop module for a project, where I was looking for a easy way to handle/store form data in session and later repopulate it easily using form API. It can be very tedious to do that manually grab the fields, store in session repopulate form. So I found a way to do it "automatically" by serializing form object and build a name => value array that I store in session, then retrieve the array later and convert it to WireInputData as it is required for form object to process. Further I needed to turn of CSRF temporarely to get around error when populating the form object. Here a example code for those interested. // generate $form // when sent if($input->post->send) { // process form $form->processInput($input->post); // if no errors if(!count($form->getErrors())){ // serialize form values and store in "shop" session namespace $formfields = $form->getAll(); $formdataKeys = $formfields->explode(function($item, $key){ return $item->name; }); $formdataValues = $formfields->explode(function($item, $key){ return $item->value; }); $formdata = array_combine($formdataKeys, $formdataValues); $session->setFor("shop", "userformdata", $formdata ); $session->redirect("nextpageurl"); } } else { // if session formdata found repopulate form object if($formdata = $session->getFor("shop", "userformdata")){ $formdataInput = new WireInputData($formdata); $form->protectCSRF = false; // to not get a CSRF validation error $form->processInput($formdataInput); // fills in form and validates it $form->protectCSRF = true; } } return $form->render();

It struck me today, as I was working on a large site, that it would be really nice if the Setup -> Fields fly-out menu would implement the "Tags" feature to group fields into sub-menus. I use Tags (defined under the 'Advanced' tab when editing a field) to neatly organize fields on the actual Setup->Fields page. It would be great if the menu was also organized the same way. A single fly-out menu of 50+ un-grouped fields isn't so useful... What do you think?

Ladies, Gentleman, GOT IT! Here it is: AllowOverride All or the second part of the httpd-vhosts.conf file here: <VirtualHost *:80> DocumentRoot "C:/mysite2" ServerName propertymarch ServerAlias propertymarch <Directory "C:/mysite2"> Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny Allow from all Require all granted </Directory> </VirtualHost> These PW forums are great. It is good to be part of this nice community. I hope this helps someone else. March

It's great but the fact that you have to select one option at a time and then it collapses and you have to reopen it can be a bit time consuming... it's fantastic otherwise Would be great if there was the option to use checkboxes as a workaround to select multiple options at once.

if you want to go further, you can use the nested accordion which allows for child accordions of the main topic; you would need to create child pages for each main subject; in that case your template might look like this: <?php $docs = $pages->get(4259); ?> <div id="docs"> <ul id="cbp-ntaccordion" class="cbp-ntaccordion"> <?php foreach($docs->children as $doc) { ?> <li> <h3 class="cbp-nttrigger"><?php echo $doc->title ?></h3> <div class="cbp-ntcontent"> <?php echo $doc->body;?> <?php if($doc->children->count()) { ?> <ul class="cbp-ntsubaccordion"> <?php foreach($doc->children as $child) { ?> <li> <h4 class="cbp-nttrigger"><?php echo $child->title?></h4> <div class="cbp-ntcontent"> <?php echo $child->body?> </div> </li> <?php } ?> </ul> <?php } ?> </div> </li> <?php } ?> </ul> </div> <script src="<?php echo $config->urls->templates ?>_admin_custom/js/jquery.cbpNTAccordion.min.js"></script> <script> $( function() { $( '#cbp-ntaccordion' ).cbpNTAccordion(); }); </script> in this code the sub-accordion is shown if there are child pages, and then it outputs the body of each child page in a sub-accordion, and it will end up looking something like this: a more advanced implementation with edit links and an add new doc for superusers: <?php $docs = $pages->get(4259); ?> <div id="docs"> <ul id="cbp-ntaccordion" class="cbp-ntaccordion"> <?php foreach($docs->children as $doc) { ?> <li> <h3 class="cbp-nttrigger"><?php echo $doc->title ?></h3> <div class="cbp-ntcontent"> <?php echo $doc->body;?> <?php if($user->hasRole('superuser')) { ?> <div style="float:right;font-size:11px;"> <a href="<?php echo $config->urls->admin?>page/edit/?id=<?php echo $doc->id?>">Edit: "<?php echo $doc->title?>"</a> </div><?php } ?> <?php if($doc->children->count()) { ?> <ul class="cbp-ntsubaccordion"> <?php foreach($doc->children as $child) { ?> <li> <h4 class="cbp-nttrigger"><?php echo $child->title?></h4> <div class="cbp-ntcontent"> <?php echo $child->body?> <?php if($user->hasRole('superuser')) { ?> <div style="float:right;font-size:11px;"> <a href="<?php echo $config->urls->admin?>page/edit/?id=<?php echo $child->id?>">Edit: "<?php echo $child->title?>"</a> </div><?php } ?> </div> </li> <?php } ?> </ul> <?php } ?> </div> </li> <?php } ?> </ul> <?php if($user->hasRole('superuser')) { ?> <div style="float:right;font-size:13px;"> <a href="<?php echo $config->urls->admin?>page/add/?parent_id=4259"> <button class="ui-button ui-widget ui-corner-all head_button_clone ui-state-default" name="button" value="Add New" type="button"><span class="ui-button-text"><i class="fa fa-plus-circle"></i> Add New Doc</span></button> </a> </div><?php } ?> </div> <script src="<?php echo $config->urls->templates ?>_admin_custom/js/jquery.cbpNTAccordion.min.js"></script> <script> $( function() { $( '#cbp-ntaccordion' ).cbpNTAccordion(); }); </script>

Some update on the site. now there is also a shop with Polish payment system payU. Its based on apeisa shop module. http://chemik-police.com/sklep/ Also would like to add that the team, the site is for is now champion of Poland

Thanks for the file. The problem is that your SVG doesn't have width and height attributes in the SVG tag. PW uses these to determine the size of the image. Not sure how best to deal with missing attributes, but I'll have a think and chat with Ryan. In the meantime, if you add: width="1200px" height="500px" to the SVG tag in the file, you'll find that it uploads just fine. BTW, I am assuming you are familiar with SVG and know that they are easily editable with a text editor - and if not, now you know EDIT: Github issue submitted: https://github.com/ryancramerdesign/ProcessWire/issues/802

@Joss - yes, i'll post the complete instructions as a new thread in tutorials, and link to that here - would that be ok? here's a first draft... https://processwire.com/talk/topic/8392-simple-built-in-docs/?p=81303

@Joss - using a super simple implementation now for docs, using admin custom pages and a nested accordion. obviously not as developed as your idea, but took about 20 minutes to setup and now this client can read the docs from their PW admin; screenshot: : *changed to single screenshot

As I've mentioned in this thread there is quite a bunch of websites that we (neuwaerts) are launching these days. Today i present to you: sgh-net.de. SGH is a german specialist for business process outsourcing (i.e. they scan all of your incoming paper mail and make it available digital or take care of your companys invoicing) . The website features plenty of (css)3d and large imagery stuff to play with. Sadly there is no english version yet. Have fun exploring and thanks for your feedback: sgh-net.de

I wonder if the Add Field dialog on the templates page could be enhanced to use the field's tags as optgroup dividers in the select field. I can see that might be useful if you have a lot of fields.

All modules now have their own short URL off mods.pw. The letter combo used is the base 62 value of the module's ProcessWire page ID minus 1000. For example "3y" translates to 1246. Just a way to keep them as short as possible.

I agree with all this. Here are the curent module naming conventions (first word in module name): Export - any module that provides site data export capabilities, especially where there may be a related Import module. Fieldtype - any module that extends the 'Fieldtype' class. Represents a data type used by ProcessWire fields. Form - any module that deals with creating/processing web forms (some crossover potential with Markup). Inputfield - any module that extends the 'Inputfield' class. Represents an HTML input widget used to collect data in the admin. Import - any module that imports data to create new data in a PW site. Jquery - any module that adds something related to jQuery/Javascript. Language - any module that provides support for other languages Process - any module that extends the 'Process' class. Typically attached to a page for handling admin actions. If it's related to another Process module (core or 3rd party) it's name should start with that module, i.e. ProcessPageEditLink is related to ProcessPageEdit. Markup - any module designed for creating or parsing markup Page - any module designed to add capabilities to PW's Page class. Textformatter - any module that extends the 'Textformatter' class, for runtime output formatting of text fields. Some of the naming conventions are based on the root class that they extend, though not all. New additions to this list likely won't be based on extending some built-in class, since there aren't any others. Though I would suggest that when a module doesn't fit in the above, it should start with the class name of the core class or module it is hooking into (not unlike the 'Page' one above). So if you are adding hooks to the Pages class, then start your module with 'Pages'. Likewise if you are adding hooks to the Session class, then start your module with 'Session'. Beyond this, the naming conventions are open ended. I guess the first thing we have to determine is: what are the major classes of modules that aren't covered above? I can't think of any at the moment, but I know they are there.