Leaderboard

I'm currently looking into Field dependencies and Repeaters. I made it work with using dependencies inside repeaters modifiying the showIf data attribute added to fieldsets to inject the repeater page suffix _repeater[PID]. This means we could use repeaters to simulate different kind of blocks using fieldsets inside repeaters along with a select where you can choose the type of fieldset you want to enter. I made a short test and it works great. Example: Repeater: Select Type (page field single select) 1203, 1204 Image-Text (fieldset with text, image field) only show if Select Type = 1203 Video-Block (fieldset with text and video url) only show if Select Type = 1204 Now I can set the fieldset visibility to show only if the select has a certain value, means you can swop the fieldsets. I'm not sure about scaleability, since the repeater has it's limits. But I think if you keep it tight with fieldsets and fields and only use a couple (maybe 5-10 types) this could be used to have blocks you can add and edit inline. What you guys think?

Hello ProcessWire community At first I like to thank and congratulate Ryan for this wonderful work and I wished that I knew Ryan a long time ago And by the way you look awesome in the overview video Ryan And now a little bet about me: My name is Faisal Halwan from Saudi Arabia. I work in web development over 14 years now, and have dealt with various content management systems and PHP scripts in general. I was always dreamed of a flexible content management system for use in almost anything or what is now called CMF or allow me to say ProcessWire Thank you Ryan, you make my dream came true Yet I couldn't find any result in for any Arabic article talking about ProcessWire I will do my best to present ProcessWire and provide support in Arabic as soon as possible. Thank you and keep up the good work

One way to do it would be to create a new template called /site/templates/bookmark.php and give it a title and URL field called 'bookmark_url'. For the code in the file: <?php if($page->bookmark_url) $session->redirect($page->bookmark_url); Now add a new page in your admin where you want the bookmark to go (like in the top navigation or in Setup), and use your new bookmark template. Enter the title and the URL you want to bookmark to and save. This is the same approach used for a front-end redirect template. In this case, you could use the same template on the front-end for that too.

It turns out that the default spelling service used by TinyMCE's spellchecker, GoogleSpell, has been discontinued. That's why everyone's spellcheckers stopped working. You can fix it by editing the config.php file included in your /site/tinymce/spellchecker/config.php file. Comment out the line referring to GoogleSpell and uncomment the line referring to PSpell or PSpellShell: // General settings //$config['general.engine'] = 'GoogleSpell'; //$config['general.engine'] = 'PSpell'; $config['general.engine'] = 'PSpellShell'; Use PSpell if your PHP has the PSpell module installed (you can check from phpinfo). Mine did not have it installed, so I used PSpellShell. If using PSpellShell: Check that this line (also in the config.php) points to the location of your "aspell": $config['PSpellShell.aspell'] = '/usr/bin/aspell'; You can determine the location by typing this in the shell: which aspell It will return the path where it is installed. After updating your config.php, double check that aspell works by typing this in the shell: echo "This file has a misspellling can you tell which word it is?" > test.txt aspell -c test.txt In most cases it should work and your TinyMCE spellchecker should start working again. If you get an error, then you may need to do more, like install a language-specific dictionary file (which you may need to ask your webhost to do).

I'm sure you can, using their API https://developers.google.com/analytics/devguides/reporting/core/v3/

You must set the output formatting to false before changing the status. Also you need to write save(), because it's a method and not a property: wire('page')->of(false); wire('page')->addStatus(Page::statusUnpublished); wire('page')->save(); wire('page')->of(true);

A small update - I have added support for import options so now you can decide whether you want to import just the fields and templates, or the entire page tree at the import stage, regardless of what is in the exported JSON file. Of course you can't import the page tree if it wasn't exported, but you can import just the fields and templates from a JSON file that contains the entire page tree. I have also added support for importing page trees directly from the repo at: https://github.com/adrianbj/ProcessWirePageLists Just choose the "Shared JSON Packages" option when importing. I haven't tackled the repeater field etc issues yet, hopefully soon. Will also be adding more shared packages soon and would love any contributions See the attached screenshot showing the direct page tree import using Ryan's awesome new admin theme

I just (like 5 mins ago) implemented "Most Viewed Pages" widget for a client. I used Wanzes excellent ProcessGoogleAnalytics module and it was easy enough pull data when it was first setup. It might be that this is not a fit for your project Martijn (if you need the data for selectors for example), but this is how I did it: $pga = wire('modules')->get("ProcessGoogleAnalytics"); $ga = new GoogleAnalyticsAPI(); $ga->auth->setClientId($pga->clientId); $ga->auth->setClientSecret($pga->clientSecret); $ga->auth->setRedirectUri($pga->page->httpUrl); $ga->setAccessToken($pga->accessToken); $ga->setAccountId($pga->accountId); $defaults = array( 'start-date' => date('Y-m-d', strtotime('-1 month')), 'end-date' => date('Y-m-d'), ); $ga->setDefaultQueryParams($defaults); $params = array( 'metrics' => 'ga:pageviews', 'dimensions' => 'ga:pagePath', 'sort' => '-ga:pageviews', 'max-results' => 11, ); $visits = $ga->query($params); $out = "<h2>Most read articles</h2><ul>"; foreach($visits['rows'] as $row) { if ($row[0] == "/") continue; // Skip the homepage, should be on top 10 always, if not, then 11 articles is shown $p = $this->pages->get($row[0]); if ( ! $p->id ) continue; // For some reason page is not found anymore... $out .= "<li><a href='$p->url'>$p->title</a></li>"; } $out .= "</ul>";

Hi, on a site I want to disable access to original images and only allow to access thumbnails and watermarked image variations. EDIT: A good solution for protecting original images can be found a bit down in this thread: Old content of this initial post:

This module redirects ID based URLs to the full SEO friendly URL Modules directory: http://modules.processwire.com/modules/process-redirect-ids/ Github: https://github.com/adrianbj/ProcessRedirectIds Very simple module that alllows you to link to pages with their page ID in the URL. The ID can be in any location in the URL. There is a config option to simply load the content to the ID based URL, rather than redirecting to the original PW url if you prefer. If you use this option, the module adds a canonical link to the page to help identify the ID based URL as a duplicate of the proper PW url so Google won't penalize you for duplicate content. For example you could do any of the following, where 1058 is the ID of the page you want to load: http://www.mysite.com/1058 http://www.mysite.com/1058/this-is-the-fancy-title http://www.mysite.com/category1/category2/1058/any-text-you-want/ http://www.mysite.com/category1/category2/any-text-you-want-1058/ Any of those will redirect to the proper URL, eg: http://www.mysite.com/this-is-the-fancy-title/ At the moment for this to work, the page ID segment of the URL must be the only segment that is all numerical, otherwise, anything goes. The reason for this module is mostly as a way to have a very simple shortlink to any page on the site, but it also allows for structuring URLs however you want with any content you want. I guess this could be abused and potentially bad for SEO! I am not sure if this is a good way to do this, so I would definitely appreciate any feedback.

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

Module for admin and front-end resizing and rasterizing of vector SVG images Requirements IMPORTANT: This module requires Imagemagick and the pecl imagick extension. For anything but simple SVGs, you must make sure imagemagick was compiled with a relatively recent version of rsvg (I know that 2.32.1 works well and presumably anything more recent should also be fine). If you don't manage your own server and the results are not good, check with your host. If everything is set up correctly, the rendered PNGs will be "perfect" representations of the SVGs. See this post below for just how much of a difference rsvg can make. How to use You must add SVG as an allowed file type for a multiple images field. Check the module configuration for a variety of settings for both PNG and JPG output options. In particular be aware of the Rasterized Images Field selector. If you choose "None" only the SVG will be stored in the images field. You can still access rasterized versions via the rasterize() method - see below for details. NB: You need to be running a recent dev version (or 2.4 stable once available) of Processwire that supports field dependencies for the configuration settings to work as expected. Once the module configuration settings are completed: Upload an SVG image and the module will create a rasterized version. You need to save the page to see the rasterized version which can then be accessed via the API like any other image. The module also adds a new method: rasterize() which can be called from your templates like: $image->rasterize(200,0)->url This method optionally resizes the vector version of the image and then rasterizes it so you can scale it infinitely and there will be no loss of quality. Make sure you point it to the svg version in your images field. Modules Directory: http://modules.processwire.com/modules/image-rasterizer/ Github: https://github.com/adrianbj/ImageRasterizer

Hi again fellow PWers, A while back I created a newUser module that added a new user when a page (student) was added. This all works great. Today I'm trying to add a delete function to this same module (as we were getting leftover users when students were deleted) but it's throwing NullPage errors. I tried changing the hookAfter to hook Before but am still getting errors. Also strangely it's causing an issue when trying to delete these pages from the trash. I'm getting a "this page cannot be deleted" error. Any pointers would be greatly appreciated ------------------------------------------------------------ <?php class Createnewuser extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Create a new user', 'version' => 101, 'summary' => 'Creates a new user and edits an existing member on saving a member page.', 'singular' => true, 'autoload' => true, ); } public function init() { $this->pages->addHookAfter('added', $this, 'createTheUser'); $this->pages->addHookAfter('save', $this, 'updateTheUser'); $this->pages->addHookBefore('delete', $this, 'deleteTheUser'); } public function createTheUser($event) { $page = $event->arguments[0]; if($page->template == 'student'){ $newuser = new User(); $newuser->of(false); $newuser->name = $page->name; $newuser->pass = $page->password; $newuser->save(); $this->message("New user also added $newuser->name."); } } public function updateTheUser($event) { $page = $event->arguments[0]; if($page->template == 'student'){ $the_user = $this->users->get("name=$page->name"); $the_user->of(false); if ($page->isChanged("password")) { $the_user->pass = $page->password; } if ($page->isChanged("email")) { $the_user->email = $page->email; } $the_user->save(); $this->message("User $the_user->name also updated."); } } public function deleteTheUser($event) { $page = $event->arguments[0]; if($page->template == 'student'){ $the_user = $this->users->get("name=$page->name"); $the_user->delete(); } } }

Marty, that is implemented here, but not yet committed. I will add that soon, since there seems to be lots of interest for Fredi lately.

Thanks for the feedback. Yes I get that users like to see what they get, but you get it when viewing/editing the blocks (click on asm list label name) and on front-end when go preview the page (unpublished pages are viewable by editors). I think it would a small price to pay for blocks in a scalable manner, easy to deal with and sort them. And as said front-end editing is something that should be considered a lot since PW makes it so easy and clients usually like it. I have also mixed feelings and am somehow aware of drawbacks and issues to could lead to. Also misuse of this, either by the developer or by the user. At the end it all comes down to what do you need to solve with this? And does this lead to bad websites/Use of it (I think most of times yes!) Currently I see it like this: My module pros - minimal easy setup - scaleability - reuse fields and blocks (would requires some complex config setup but possible) - blocks are pages - can use repeaters ... cons - no direct inline editing (if a concern at all) - don't see a way to search via simple API selectors (would require special workarounds, a lot of work) - not easy to limit and reuse things, a lot of work would need to be put in module (grows complexity) ... Using repeaters with conditionals (if supported by PW at some point) pros - easily create different repeaters with different types - inline editing - able to use in simple search API selectors (repeater.field) - repeaters are pages ... cons - doesn't scale as good - some larger setup required - not able to reuse fields and sets created in a repeater - dependency on repeaters - can't use repeaters (inside repeaters) ... and not to leave out already possible approach Using child pages pros - straight forward adding them, almost no setup - preview and editing easy possible on front-end - no dependency - reuse fields, template, and content - they are pages ... cons - no inline editing, different approach (but clients usually get this easily) - could interfere with other child pages (although this can be solved if you put them in a global branch and append them using page selects) - needs workaround for searches using API (but easier as they're direct childs) ... somehow After all I'm looking also further and question things like: what about future major features PW maybe introduce and support in future? Import-Export, versioning, drafts etc. Ever thought of that? Currently I don't know where all this leads us. As said this current module only shows a proof of concept and it maybe one possible to further develop. But first I want to make sure it would be the way to go. I think to use pages in some or other way is a good way to go as you benefit from all features a page can have with all it's API, without relying on a new proprietary system. So this is maybe more what's behind it and more technical, but I think I would love to hear other developers to look and think about this.

I could see something like this being used on image-heavy sites. Someone here flagged the idea of creating an Amazon S3 uploader for files and images. I've got something like this working on an EE site I look after. It keeps the PW install light so if you need to move it to another host it's not such a major undertaking. Backups are simpler too.

Just my opinion. Base font size currently is 10px/20px (body) and just set using #id's to 1.3em. I don't understand why it is has to be this way, as I'm long time used to working with 100%, font-size: 1em for starting point along with media-queries in em too. Some related reading I just found about this why this seems like a good practice: http://filamentgroup.com/lab/how_we_learned_to_leave_body_font_size_alone/ http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/ Defining font-size should not happen on containers but on html set to 100% and body on 1em as default first, and then on text elements. We don't think in pixels anymore. In this case this #content 1.3em is just scaling it up from the 10px/20px which seems ok but there's drawback as you in some cases can't overwrite it easily on inherited elements without using #content in the selector again. I'm also in general not very convinced about how the admin default css is built (but it get's better and better) and think it could be cleaned and improved a lot. There's a lot of redundant, unnecessary (and some not even having an effect at all!) definitions it even goes into performance rendering (even if very minimal). I think it need's a global scope rethink and rewrite/cleanup and I would be willing to help where I can. Sorry I'm not so good at explaining and communicate those things with text and even so more not in my mother language. - Desing wise I think colors are important, (I just think not as many as it has now, I count over 10!)) but good UI design is much about font type, spacings, and how elements are presented. Good UI design doesn't distract and confuse, I can't currently say that this theme does solve anything from the default previous theme. Colors should be used to emphasize certain things and elements not brand it. My opinion. People I know that don't like PW aren't saying colors, but general UI design and style not being modern. And that comes down to how big a font is and how much spacing it has.

It's a leftover from the old admin theme (I didn't create these files from scratch). You are right, we can drop this left/right padding as there isn't any need for it. Also a leftover from the old admin theme. In 2009/2010 there was still a little bit of lingering IE6/IE7 bad habits–which meant using absolute positioning when floats were more appropriate largely because IE was not consistent with floats. Obviously that's not the case anymore. I think your suggestion to change these to floats makes sense. Though also not sure it really matters much in this case, but I do prefer floats from the responsive side, so that's a good enough reason. Your screenshot is too bold for my taste, but maybe it makes sense for one of the color themes to take a bold approach like this. I understand that very often what looks better depends somewhat on how the platform and hardware/screen render type, so it's good to provide options. I'm not familiar with the outline you are talking about (Chrome OS X), but will try it out and add it if it provides some benefit in Windows or another browser or something. Kind of depends on the screen, it's quite visible here. But I see no harm in increasing the value. It's preferable to do it with padding rather than line-height since it's possible for long titles to wrap, and we want wrapped titles to still look like a single item. But I am not a fan of increasing the padding or line height here, as it just means a lot more scrolling on the sites I work on (which tend to have lots of pages). Again though, I see no problem with providing this as an option in one of the color themes if people find it more attractive. I find it less attractive myself, but it's all subjective. I think a good goal here is to support a broader range of preferences by providing more options, and so this may be one of them. ProcessWire is not a corporation so we don't have corporate colors. But we do have brand colors, and I think we will stick to them for our branding and marketing. But I'm feeling like the application itself should be less branded... would rather have people think of it as a tool like their text editor. It bothers me that a seemingly large group of people have ignored ProcessWire largely because they don't like the way the admin looks. And the colors are one of the first things mentioned. Many of potential audience thinks they look childish: light blues and pink, which are also known as baby boy and baby girl colors. I like the colors myself (a lot), but have heard it enough objections to know it's not an isolated opinion. Those people aren't here to tell us about it in the forums because they were turned off by subjective things before they got to know why it would be a great tool for them. So I wonder if the admin needs to be more neutral and not defined by colors or brand, but by its usefulness as a tool. I want people to focus on the tool and not on the colors, because the colors really have nothing to do with the tool at all. While there has to be default, it should be fairly neutral and easy to change. Ideally it would be selectable from the installer so that it's clear from the beginning that it's a tool to get stuff done more than a brand to buy into. By the same token, I wonder if there shouldn't even be a PW logo in the admin, or if we should make it something the user can easily replace with their client's logo. With regard to color schemes, I'm also hoping some others here that are better at it than me will put some together. I think I've setup some good starting points that I like, but colors are always subjective. I think someone else can do better here, so I've tried to make it as easy as possible by isolating all the components of the color scheme in a separate file that can be changed easily. So if anyone is interested in experimenting with colors, please do and post your results when you've got something that you think looks good. These are standard jQuery ui-menus, which are meant to follow the scale of select boxes (I think that's what they were trying to do anyway). I'm not yet sure if I can make major adjustments to them without affecting other jQuery UI widgets that I don't want to, but I can experiment. However, the plan is that these will descend another level for templates and fields (which can potentially include a lot of nav items) so I think it has to be a careful balance. This is something that I can confirm is very much affected by your screen. I have two screens connected to my computer, and I can barely see the lines on one of them, while the lines are nearly too dark on the other. So what you see now is a compromise between the two in finding the right darkness level for them, based on my own screens. No doubt we'll want to provide higher contrast options here in one or more of the color themes, to account for these variations. But rather than basing it on my screens, it would be good to hear from more people to see where the right balance is for visibility of the box lines. I've tried it both ways. To my eyes it looks whiter, but not cleaner. It's subjective of course. My personal preference is to have a color, a line or something to make navigation part of an interface with visual hierarchy that rather than free floating. But I think it doesn't hurt to experiment here in one of the color options. I actually thought it worked ok that way when testing it in the Modern color theme. I don't think we can legally connect an admin theme with my TypeKit account. Maybe there is another resource we can use for this, but it's got to be something that doesn't require connecting to an outside service. The typeface also has to be one that is fairly generic. Arial is about perfect IMO due to it's anonymity... keeps the focus on the content without the type influencing the personality or suggesting style. The goals in the admin are entirely different from the goals on the marketing/brand site we're on now. Arial doesn't do anything for me (which is partly why I think it's a good fit in this case), but if we can find something that has similar characteristics while looking newer or more professional, I think that would be a desirable thing.

I din't come to the forum a lot lately, but I did install the theme to try it out. Great effort Ryan! There lots of good things in it. I don't like the color schemes very much and I think it's not very positive if you are planning to use the warm as default because in my opinion it's important to keep the corporate colors of PW. I think the warm scheme is the one that works better for now, not because of the colors, but because it might have had more love than the others from your side Two new things I don't like: The dropdowns are too stuffed and clunky. the items need some space to breath. I think you went too far by removing the field boxes, I feel like everything is floating without an order. The boxes could be kept, but be simply lighter and less present then before. Two things that are not that important but would make the theme look more modern: Removing the color on that second area bellow the menu and making it lower seems to make the theme look cleaner (see screenshot) Shouldn't we let Helvetica and Arial have a rest (Arial in my case)? Let's try open-sans since it's the one used on the website.

If using ProCache, it would be kind of defeating some of the benefit of it if you are still loading ProcessWire for every request to update a view counter. I'd think you might be better off using an external service like Google Analytics to keep track of this for you. It already does this if you are using it, but of course that's not data you can easily pull back in to sort pages, etc. (as far as I know)

Hi all, given that "customfield" is unique without spaces and 64 characters long, this returns a null page: $myuser = $users->get("customfield=eebc849774d363186b6ebc4e3bc86a03be2a03b6d4411a4a91b3a70faa4a39b2"); The page/user still exists with that equation ("customfield" is set to "Text" and added to the Users-Template, in Admin the user is shown with the right "customfield". Is there a maximum parameter size for a selector? Regards, Thomas

Tested out and I was able to duplicate here. It looks like we had a 50 character max limit for queries sent to the fulltext index. I have updated this to be 500 (consistent with the selector engine's max value length) on the dev branch. That seems to fix it here.

Add this to your template file: $useMain = false; See the note about this in the /site/templates/_init.php file

<joe>However it still does not solve the problem that I want the user to have only two choices for aligning the image when inserting it. (The Image-Interceptor can be set to either align the image left or right or "Alignment: inherit" - leaving the choice to the user when inserting the image, but there I want to eliminate "No Alignment" or "Align Center" as they mess up the look of the page.</joe> You can chose No-Alignment, then align_no_align class is added to the image. Beware that Images are inline elements ! You have to do the CSS by your self. if "Link to Larger Version?" is checked, there will be a link to a larger version. Don't know what is confusing about that. And you can't always "lightbox" all images by default. ps, for your "hacking", consider styling ( read display: none ) to alignment options

Needed that badly, perfect timing! I didn't know about language alternate fields. That's a good enough solution for now.

I had the same problem. I just thought I had missed something I fixed it by renaming main-classic.css to main.css and replacing that one with the original.

[quotamos] $pages->find('categories='.$page->category); $pages->find("categories={$page->category}"); [/quotamos] that not.prolem those.is exacly same to php

Hi Chrizz, welcome to the forums. Here is code for a module that hooks into the event you are looking for. Maybe it is a good starting point for you: http://processwire.com/talk/topic/4517-random-images-file-name/#entry44392 --- Also worth to look at, (if you don't know it now), is Somas ImagesManager: http://processwire.com/talk/topic/3219-images-manager-alpha/ and maybe for watermarking the PageImageManipulator: http://processwire.com/talk/topic/4264-release-page-image-manipulator/ --- EDIT: @Chrizz: after rereading your post I think the best way for you would be to use Somas ImagesManager because it does most of what you want and if you need to adjust something you also can hook into it like I have done with this module: http://processwire.com/talk/topic/3398-working-with-processwire-getting-exif-data-from-images/#entry33552

@choppingblock: just like the exception says, '%=' isn't implemented with page type fields, as it's not needed there. I've explained this in more detail in another thread.

You got the who and what but not the where. Access is defined per template and inherited. So simplest is to edit home template and define access for your new role there.

Only through JS.

I just went and added support for pagination. I pushed the update to the dev branch of the module you find here: https://github.com/somatonic/ModulesManager/tree/dev Still working out on the details for categories. Currently it just filters on a per page basis, so it possible there's a page not showing anything if category filter is set. Once you changed the limit in modules settings, you should hit refresh first on the ModulesManager screen to delete all cache files. It will create a cache file per page. So it all works now with unlimited modules but still need some work and I'm waiting for the JSON feed from modules.processwire.com to allow for more filtering.

I completely agree with Antii that this is one of the strongest points of PW. Democracy in Open source projects can some times take to delayings and strange decisions. I think it's great that all final decisions are made by one person that knows very well in which direction the project should go.

owzim: one thing you might want to mention. We (www.avoine.fi) are company with around 2.5 - 3 million euros revenue for this year. Good part of that (all client websites and -services) comes from ProcessWire. We have also build lots of new software using ProcessWire. Fully dedicated to this platform in many ways: 5 developers working with ProcessWire, sponsoring the core development and also contributing to the core and releasing open source modules. And I see "strong leader" model as a strength for ProcessWire development. Software development is not road building: you don't do it faster nor better by throwing more people to the mix. It of course requires that we have great leader, and that we certainly do have!