Leaderboard

@Robin S Have a look in the PageTraversal class (/wire/core/PageTraversal.php), and the _next() method. It's all in there. The gist of it is that it works roughly the same as before, with one big difference: rather than loading all the sibling pages (Page objects), it loads all the IDs instead (integers), in order. It doesn't always have to load them all either, just enough to determine relative positions. Once its found the needed ID(s), it converts them to Page object(s). It also involved upgrades to the PageFinder class so that it could support startAfterID and stopBeforeID options. If you look at the end of the PageTraversal class, you'll see an earlier implementation that I worked with for a couple of days before coming across a couple of situations I just could not get it to work in (and became clear it never could), so ultimately had to abandon it. However, since it relies on how sibling pages are sorted (rather than relative positions), it doesn't have to load near as many, making it potentially faster (and more memory efficient) if there are thousands or millions of siblings. Though in my own testing, it was always slower until the scale got really large. Not to mention, it's a whole lot more complex, and can't cover all situations. But I'm leaving it commented out in there for a little while (for reference) since so much work went into it before finding a much simpler solution.

You're not the first person to say this so there must be something to it, but that is not my experience. As a PW learner I haven't found working with modules to be a lot more difficult than working with any other aspect of PW / PHP and the docs seem pretty good to me. My experience has been that module development is challenging, but in a good way - you just get stuck in, debug issues as they arise, and ask for help in the forums when you get stuck. This makes me wonder if you are holding back from actually starting on your module while you do 'research' - I'm not sure this is the best way to learn module development and my suggestion is just make a start and learn as you go. Like many things in PW, I think you'll find it's a lot simpler and easier than you anticipate when you're on the outside looking in. Part of the problem with providing detailed documentation for something like module development is that the subject is so broad - a module can be created for any purpose and whoever is writing the docs can't know what you might want to do in your module. By analogy, it's like if you are learning to cook: you won't find much if you are searching for documentation on how to cook in general because the topic is too broad. Instead you have to decide what you want to cook and then look for help with that - how to make a chocolate cake or how to pluck a goose. Maybe you can say a bit about what you want your module to do?

There are various small modules to start from, which include the few basics and everything else is really up to what's needed for your module. There's Helloworld.module in each installation as a plain module (with opt. external config here), ProcessHello as starting point for custom backend modules and FieldtypeEvents for Fieldtype/Inputfield development. If you have those the best followup docs are probably processwire itself. Almost everything beyond the core is a module. You want to have a table rendered in an admin page – Take a look at e.g. ProcessField or ProcessTemplate, which both use such a table. You'll soon notice MarkupAdminDataTable with is another module just for rendering these tables. Basically everything with module infos and a way to tell it own classname is a module. It's described more detailed here: https://processwire.com/api/ref/module/. It can only get more detailed if one is asking for a module doing specific things, e.g. hooks, process modules, textformatters, error messages, table rendering and such.

Haven't used it now, but already like it! (have had a look to the readme!) Below an example of a root parent and a first level child:

As described in this post (https://processwire.com/talk/topic/8551-custom-urls-for-pages/?p=82742) the option 'Name Format Children' under the tab 'Family' in template settings doesn't work properly and also not as expected. I had a look inside the code and made some changes which are working properly, which offers much more options, more consistency and less code too. The result is the following. You have 3 Options for generating name and title, which could be combined in endless variations. Name is always derived from title, same like creating pages manually. type date: if function detects # character anywhere in the string, conversion will be: deletion of # and string will be used as format parameter for PHP date() function type field: if string is a fieldname of the parent page the value of this field will be used type string: if string doesn't fit to the 2 preceeding it will be taken as it is All parts (separated by comma) will be composed in the order of setting. You can use unlimited numbers of parts I made a pull request on github: https://github.com/ryancramerdesign/ProcessWire/pull/831 Example screenshots Setting ... will result in

Aligator (wip) Processwire Module to render a nested tree starting from a single root or an array of pages. Aligator is similar to MarkupSimpleNavigation but has a different approach of how to define the markup for your menu. It doesn't assume any markup or classes. It's up to you to define them where needed. It's less plug and play and requires some more advanced knowledge of ProcessWire, as some additional setup and coding is needed. But allows for powerful and easier customization without using hooks. Aligator uses callback functions to achieve this. Additionally a selector can be used to filter the children for your navigation. Note: This module is a fun project trying to find simple configurable method to render navigations. It's a work in progress and there might be major changes to how the module works. See further infos and examples on the repository: https://github.com/somatonic/Aligator

TemplateEnginePug (formally TemplateEngineJade) This module adds Pug templates to the TemplateEngineFactory. It uses https://github.com/pug-php/pug to render templates. doctype html html(lang='en') head meta(http-equiv='content-type', content='text/html; charset=utf-8') title= $page->title link(rel='stylesheet', type='text/css', href=$config->urls->templates . 'styles/main.css') body include header.pug h1= $page->title if $page->editable() p: a(href=$page->editURL) Edit Project on GitHub: github.com/dreerr/TemplateEnginePug Project in modules directory: modules.processwire.com/modules/template-engine-pug/ For common problems/features/questions about the Factory, use the TemplateEngineFactory thread.

This week updates were focused on covering GitHub issue reports and feature requests, plus some great new performance improvements to our page traversal methods… https://processwire.com/blog/posts/pw-3.0.24/

I think there should be an easy way for developers to offer commercial modules like Ryan's pro modules. More extensive, userfriendly and generally more professional modules will become available Commercial modules will be attractive for bigger projects in terms of support / reliability ... What is the communities but especially Ryan's opinion onto this subject? Are there any paid modules other than Ryan's pro modules available at this time? Another option could be donations or maybe licensing for commercial usage only ... Please don't get me wrong. I know that contributing is important ... This question is about real big and time consuming ideas that you would not implement without a way to monetize. Looking forward to your opinions

@tpr - Thanks, glad you like it. I have started building Jumplinks 2 from the ground up, but haven't had the time to continue work on it of late. With regards to the state-toggle: I can implement this feature, but it would be turned off by default. That said, if the feature gets enabled, the jumplinks would all be created to redirect with status code 302/307 (actuallly not 100% sure which one is better). That said, is isn't necessary to do so, but not doing so would mean going against the intention of the different HTTP codes. As for previews: these can be somewhat difficult, giving consideration to parameters - I think I may have brought this up before here. It would be easy to preview jumplinks that don't have parameters, but those that do have them would need user input in order to test. This is all on my to-do list for the new module, which will be compatible with both PW 2.8 and 3.0.

You should really test your selectors first before packing it into the paginator and trying to make sense of it. But I finally managed to setup a small test case and found a few issues, not releated to sorting, but to counting the total number of pages. It seems like there's no possible solution to wrap multiple selectors, where at least one does use or-groups, to one combined to run a $pages->count() on.

There is no $alreadySelectedElements, because we're not loading any items before those we really need. That's the crux in pagination. It should at best work without the runtime even knowing which items came before the current page, because otherwise there will always be scalability issues.

Yeah, that's probably the only way for this to work without needing to exactly know which items where in pages before the current. The NoDuplicates class is more a failed attempt

Apparently the child has a higher z-index

You have the whole API available to you for module development. The examples above are not specific to modules, but are methods of the Wire class. https://processwire.com/api/ref/wire/message/ https://processwire.com/api/ref/wire/error/ My go-to pages for module-specific info are: https://processwire.com/api/ref/module/ https://processwire.com/blog/posts/new-module-configuration-options/

Hi guys I feel certain that when I export field and template data using the built-in tools in the PW admin there must be a way to use this JSON in my own modules as part of the install routine to set up these fields and templates, but I can't figure it out. Any ideas?

@dreerr Thank you for this module. Wanted to use jade with PW for a long time. Is there a way to define global variables that can be used in any template or in a jade layout file? Thanks

v016 was uploaded today to GitHub: enable setting template latte file with/without extension ($view->viewFile = 'basic-page' and $view->viewFile = 'basic-page.latte') $view->json_encode returns JSON encoded string/markup. Possible values are true and PHP's json_encode options (eg. JSON_PRETTY_PRINT). if "viewFile" begins with "//", $config->paths->templates and viewDir is not prepended to the view path These updates make it easier to get Ajax results, and allow placing latte files outside templates/views directory. The latter was also possible earlier using relative paths ("../"), but now it's more flexible. Getting json output was only possible using wireRenderFile() and applying json_encode() manually, which was less convenient.

I got it working, but the "General" context will be gone. I think it's even better this way. Will upload a new version soon, after testing the different variations a bit.

Changed the git so that jade-php is included in a normal download. Version 1.0.2 brings also some additional settings for stream and a problem we experienced with Suhosin

Since there are a lot of topics about the same theme, I decided to write a small module which overwrites the core function ___SetupPageName(). The module allows now to populate the page name using proprietary date() function. Works like PHP date() with follwing exceptions: Everything between the brackets is detected as format string, meaning no 2nd parameter possible. No need to use quotes around the format string. Spaces not allowed. from any page property, page field including subfields, parent property, parent field etc. Meaning everything what you get with $page->get(); including dot syntax. The function will give error and warnings in case of unproper settings, but creates the page with name 'untitled' anyway. Download here: http://modules.processwire.com/modules/process-setup-page-name/ Some Examples The following settings in parent template 'Name Format Children' will assign name immediately. date(Y) date('Y-m-d') parent.title parent.parent.title parent.id template.id assign name after page saving and/or population of depending field. Overwrites 'untitled' after all fields which are defined in parent template are populated. id (any other page property) pagefieldname, multiple pagefieldnames show a warning. pagefieldname (value not populated)show an error. date() // empty, no format assigned date(Y // missing closing bracket date(Y md) // unallowed space notexistingfieldname notexistingproperty existingfield.notexistingsubfield The function in the module ___SetupPageName() could be completely copied as is to the core class $pages. @Ryan Would be nice to see this in core. Related topics: https://processwire.com/talk/topic/8576-name-format-children/ https://processwire.com/talk/topic/8217-name-format-for-children-based-on-any-field-not-just-title/ https://processwire.com/talk/topic/11628-custom-page-name/ https://processwire.com/talk/topic/11349-page-add-step-not-being-skipped-when-name-format-for-children-is-set/ https://processwire.com/talk/topic/10701-automatic-page-name-using-processpageaddexecute-and-pagetable/ https://processwire.com/talk/topic/10208-pagetable-automatic-page-name-format-when-multiple-templates-allowed/ https://processwire.com/talk/topic/9979-name-format-for-children-for-multiple-allowed-templates-for-children/ https://processwire.com/api/modules/process-template/ Any recommandations after testing welcome. Download here: Download here: http://modules.processwire.com/modules/process-setup-page-name/ Edit: small enhancement to prevent display of warning twice. 23.12.15 multiple values possible now 24.12.15 made compatible with PW 3.x 27.12.15 Update Version 1.0.8 09.01.16 Update Version 1.1.0

Here's an example module that removes "Add New" button(s) on InputfieldPageTable on a condition (here if there's 2 ore more entries). Hook before InputfieldPageTable::render, then add hook after InputfieldButton::render. Since InputfieldButton is used by PageTable, we just use that hook to empty the returned markup for the button. Then remove that button hook after the InputfieldPageTable rendered. https://gist.github.com/somatonic/c9db5c43f10d050bb14d