Leaderboard

Another one out of the door: http://apollon.de Pretty basic usage of PW, pagetableextended for the content blocks, flexible sidebar, some effects (their wish)

Just to add to kongondo's info, there is a little helper variable ($database) for PDO database work: $sql = "Your table and field creation statement"; $query = $database->prepare($sql); $query->execute();

I haven't seen any. You have at least two choices: 1. Create a Fieldtype module that you can attach to a page and use that to input your data. The page would mainly be a container for your input fields, although you would have to think about how to retrieve your stored data in which case the page ID might be handy. Behind the scenes, Fieldtype modules directly interact with the db - saving -> sleepValue() and retrieving -> wakeupValue(). This assumes that you will create a table only once for holding your data (when you create fields that use the Fieldtype) after which you will just be adding/modifying/removing db rows in THAT table. You would also be able to use raw MySQL if you wanted to. If you choose that, I highly recommend you use prepared statements for both security and future compatibility with ProcessWire. Have a look at the module matrix for ideas if you wish. 2. Create a ProcessModule with input fields to send/display your data. In this case you would have to use raw SQL to CRUD your data. Again use prepared statements and strict validation. Here too I assume you want to create only one table before hand (e.g. on install of the module - see changelog module for instance) and use that to store your data. There could be better ways of approaching this.....but I would create the tables once before-hand (on install of your module).

Which version of processwire are you using? In 2.5 should be a admin page called "Find", which allows for exactly that. To predefine multiple of those lists there's the pro version of this module in the store: https://processwire.com/talk/store/product/16-listerpro-single/. It allows for easy creation of custom listers and a few things more.

@horst in the LanguageSupportPageNames.module I guess. It's evaluated with some AI to get the right language and page. Once the language is determined by the requested url the user language is set on runtime. It's not saved in DB of course. This would load the cached user already with changed language. This is determined very early before page renders etc. So only way without adding your own field to manage this, would be to save the language to the user with a new property (at runtime) and this should happen before LanguageSupportPageNames does it's job. In template code you won't be able to do this unless you do a DB manual query. So an autoload module would do that with an added hook line of code in the init() (see HelloWorld.module) public function init() { $this->wire("user")->savedLanguage = $this->wire("user")->language; } and then use in templates: echo $user->savedLanguage->name;

Get it from GitHub Setup Just put the module in you modules directory and install it via admin. Intro This module might come in handy if you like to keep your templates clean and free of unreadable and unmaintainable string concatenations and even free of any logic. It also comes with some handy features besides just embedding JS, CSS and image assets, see below. Yikes! <link href="<?php echo $config->urls->templates . 'styles/foo.css'; ?>"> <link href="<?php echo $config->urls->templates . 'styles/bar.css'; ?>"> <script src="<?php echo $config->urls->templates . 'scripts/foo.js'; ?>"></script> <script src="<?php echo $config->urls->templates . 'scripts/bar.js'; ?>"></script> <img src="<?php echo $config->urls->templates . 'images/sky-scraper.jpg'; ?>" alt="Some huge building"> <img src="<?php echo $config->urls->templates . 'images/owzim.jpg'; ?>" alt="Handsome!"> Way cleaner <?php echo $asset->css('foo'); ?> <?php echo $asset->js('foo'); ?> <?php echo $asset->img('sky-scraper.jpg', 'Some huge building'); ?> or with short syntax <?= $asset->css('bar') ?> <?= $asset->js('bar') ?> <?= $asset->img('owzim.jpg', 'Handsome!') ?> And prettier if you're using Twig {{ asset.css('foo') }} {{ asset.css('bar') }} {{ asset.js('foo') }} {{ asset.js('bar') }} {{ asset.img('sky-scraper.jpg', 'Some huge building') }} {{ asset.img('owzim.jpg', 'Handsome!') }} Usage JS example Let's use the js method an its configuration as an example, and assume we have the following files located in /site/templates/scripts - index.js - index.min.js - main.js $config->blick = array( 'jsPath' => $config->paths->templates . 'scripts', 'jsUrl' => $config->urls->templates . 'scripts', 'jsMarkup' => '<script src="{url}"></script>', 'jsDefault' => 'markup', 'jsVersioning' => true, 'jsVersioningFormat' => '?v={version}', 'jsMin' => true, 'jsMinFormat' => "{file}.min.{ext}", ); $asset = $modules->get('Blick'); $asset->js('index')->url; // returns /site/templates/scripts/index.min.js?v=1426170460935 // 'min' and version parameter added, which was fetched from the file modified date $asset->js('main')->url; // returns /site/templates/scripts/main.js?v=1426170460935 // without 'min', because there is no main.min.js $asset->js('main'); // returns <script src="/site/templates/scripts/main.js"></script> // because 'jsDefault' is set to 'markup' // you can also access it explicitly via $asset->js('main')->markup $asset->js('http://code.jquery.com/jquery-2.1.3.js'); // returns <script src="http://code.jquery.com/jquery-2.1.3.js"></script> // nothing is modified here, because it's a remote url You can use the file name with or without extension. Adding a version parameter only takes place, if jsVersioning is set to true, it's a local file and it exists. Modifying the file name to include min only takes place, if jsMin is set to true, it's a local file and it exists. The same applies for the $asset->css('file') method: $config->blick = array( 'cssPath' => $config->paths->templates . 'styles', 'cssUrl' => $config->urls->templates . 'styles', // and so on ... ); IMG example the img method lets you include images, crop and resize them, without them having to be a page image. $config->blick = array( 'imgPath' => $config->paths->templates . 'images', 'imgUrl' => $config->urls->templates . 'images', 'imgMarkup' => '<img {attrs} src="{url}" alt="{0}">', 'imgDefault' => 'markup', 'imgVariationSubDir' => 'variations', ); $asset = $modules->get('Blick'); $asset->img('sky-scraper.jpg')->url; // returns /site/templates/images/sky-scraper.jpg $asset->img('sky-scraper.jpg', 'Some huge building'); // returns <img src="/site/templates/images/sky-scraper.jpg" alt="Some huge building"> // any arguments following the filename are passed as an array // in this case the alt value is the 0th argument, so {0} get's replaced // you can set as many arguments as you want in 'imgMarkup' $asset->img('sky-scraper.jpg')->size(100, 100)->url; // returns /site/templates/images/variations/sky-scraper.100x100.jpg // the resized image is put into a subdir 'variations' as configured in 'imgVariationSubDir' // if 'imgVariationSubDir' is left empty, the variation will be put in the same directory $asset->img('sky-scraper.jpg', 'Some huge building')->attr('title', 'Some huge building'); // returns <img title="Some huge building" src="/site/templates/images/sky-scraper.jpg" alt="Some huge building"> // the resized image is put into a subdir 'variations' as configured in 'imgVariationSubDir' // if 'imgVariationSubDir' is left empty, the variation will be put in the same directory You can also setup predefined variation settings in imgVariations $config->blick = array( 'imgVariations' => array( 'header' => array( 'width' => 960, 'height' => 360, 'options' => array( 'suffix' => 'header', ), ), 'person' => array( // and so on ... ), ), ); And call it like so: $asset->img('sky-scraper.jpg')->variant('header')->url; // returns /site/templates/images/variations/sky-scraper.960x360-header.jpg $asset->img('sky-scraper.jpg')->variant('header', 50)->url; // returns /site/templates/images/variations/sky-scraper.480x180-header.jpg Attributes example Since version 0.4.0 you don't need to create arbitrary variable placeholders, if you want to use attributes only. Now you can use the {attrs} placeholder and set the attributes via $asset->attr('name', 'value'). The name argument can also be multiple names, split by a pipe |. $config->blick = array( // ... 'imgMarkup' => '<img {attrs} src="{url}">', // ... ); $asset->img('sky-scraper.jpg')->attr('alt|title', 'Some huge building'); // returns <img alt="Some huge building" title="Some huge building" src="/site/templates/images/sky-scraper.jpg" > Using files that are not in the configured directory If you want to include files, that are neither in the configured directory nor in one of its sub directores, just use an absolute path (actually, relative to your /site directory. $asset->js($config->urls->SomeModule . 'scripts/file-in-root'); Autoload the module If you don't want to include the module manually via $assets = $modules->get('Blick'); you can set it to be autoloaded under a custom name: $config->blick['autoloadAs'] = 'fiddle'; Now it becomes automatically available in your templates under the name fiddle $fiddle->css('foo'); $fiddle->js('foo'); $fiddle->img('baz.png', 'qux'); Please note, that, if you're using the TemplateTwigReplace.module you will have to add your chosen autoload name to the Auto-import fuel list on the module's config page. See config-example.php for all configurable settings. Change Log 0.5.0 add optional scale argument to variant-method: $asset->img('foo.jpg')->variant('header', 50) 0.4.0 add possibility to get/set and render attributes (see section Attributes example) 0.3.0 add $asset->variant('name') alias for $asset->getVariation('name') 0.2.0 fixes and internal refactorings 0.1.0 initial version

A quick Google search turned up: "That looks like you're using an opcode cache (APC, eAccellerator, etc) that is not compatible with the version of PHP you are running. But probably eAccelleator, which is hopelessly out of date." Source: http://fuelphp.com/forums/discussion/11832/fatal-error-invalid-opcode-15318- I would check eAccellerator config first.

Just in case anyone else stumbles on this. Adding include=hidden or include=all to your selector can help troubleshoot when you aren't getting any results. $my_array = $pages->find("template=xxxx, include=hidden");

Ah, thanks for the explanation. It is very useful to analyze code or test it against scenarios, also if done staticly. But it also can do a lot of harm or result in the wrong direction. I give you a real live example about static analysis that happens to me right a few days ago: Google analyzes websites due to the user experiences with mobile devices. They have sent me a message with their analyzis result where they say that I have to change some things to full fit their requirements, otherwise they don't list those pages in search results requested from mobiles. One of their usefull tips and requirements is: I should avoid calling a JS-resource in the html head, I should not call external resources above the fold! Otherwise it would be not mobile friendly. (Tada!) But in fact, the resource I call there is a very little JS file that don't use dependencies, it just checks if the site is viewed by a mobile device. And if it detects a mobile device it sets some things to avoid overhead and loading of to many resources etc. (like limiting infinite adding to only 2 items instaed of 16 with a desktop, fetching way smaller images, adds a mobile class to the body tag to derive the correct mobile friendly CSS styles from it, etc.) You also should know that all other resources the page needs are: one google-fonts call, one minified css file, and one minified js file which is called just before the body close tag. Also this site uses ProCache and is responding quick like hell. As I can see, in this case it is pretty stupid and useless to follow some static rules, it results exactly in the opposite direction. (If I would call the mobile checker beneath the fold! it could be that there were already to much items (pre)loaded; that the content needs to be rebuilded, rearranged according to the to late added mobile class to the body tag; the fetched images were to big, etc. etc) In fact, the whole users experiences, including those on tablets and desktops (not only those on mobiles), depends on calling this little JS early! If they simply would have built in some logic, it could be a helpful initiative, but how it is used now it is dumb and ignorant.

None that I'm aware of. Of course you can always use PageFinder for this, but it's going to look a bit hacky: $selectors = new Selectors("template=blog-post, limit=5, sort=name"); $pagefinder = new PageFinder(); $options = array('returnVerbose' => true); $sql = $pagefinder->getQuery($selectors->getArray(), $options)->getQuery(); // .. and so on, depending on what exactly you're looking for

Take a look at the AmazonS3CloudFront module - I was using Hani's .htaccess method but am now using S3/CloudFront + signed URLs to deliver content securely. Works great and also takes the load of supplying the file off the web server.

Hello there Yesterday we at update AG relaunched the new 1815.ch news portal of Mengis Medien AG. It's a big new portal of a local newspapers here in Wallis Switzerland. That's where the Matterhorn is also It was a thrill to work on this project using ProcessWire. We're still working out some details and adding more stuff in future. There's a lot going on and it has quite lot of traffic. 60k+ pages at the moment. Currently it serves 18k+ articles plus a lot of other data that are just pages. But will grow a lot. The portal has currently around 7k+ user registered. Lots of imports and exports are going on in the background. That mostly are XML feeds or data being uploaded to server. Some news are imported and automated. While they have different teams creating articles apart from the imports of their newspaper also via XML. http://www.1815.ch

Is it a case of: Or...? If you are able to fetch (i.e. $my_array is NOT empty) but not display, then, as suggested, check the template file. If you cannot access (i.e. returns nothing), then check access controls, e.g. are the pages hidden? For instance, 'find' will not retrieve hidden pages although 'get' will...

It seems like you would need to change the rewrite base in the .htaccess. That's the most obvious thing that would cause this behavoir.

I didn't noticed the following topic: Fallen at the first hurdle... I can definitely unterstand your point. Now you should be able to install the module the normal way. I removed the submodule and included the mobiledetect library via composer. Therefore the including path for the library changed but this doesn't matter for you. There is a new release version 0.0.4.

@Horst: without taking this too far off-topic, hopefully, I couldn't agree more; both about static code analysis in general (I've written multiple lengthy posts about that here and in GitHub, and have a half-finished blog post on the way too) and your real-world example. My opinion is influenced by the fact that I don't use modern IDEs at all, though, so take it with a grain of salt. Google has apparently increased the weight of those "above the fold" rules, and while they have good intentions, in many cases those have very little to do with actual mobile usability (or speed, for that matter). If it wasn't Google, I'd disregard the whole thing as another well-intending idea hindered by broken implementation, but because their opinion matters a great deal (from search engine traffic point of view), it seems that I'm going to have to make some sites worse than they are now (for humans) in order to make robots happy

Well, in fact this was worded the wrong way around, for sure it's the IDE that should support things that make it easy to work with a piece of code and not the other way around. That said, when writing a piece of software the author can make it more or less easy to do static analysis of the code. The information that is gatherable by static analysis enables IDEs to do their "magic" in providing all kinds of convenience when working with code (look at PhpStorm's features to see what this might include). It makes it also more easy to work interactively with a debugger like Xdebug, or code quality tools like PHP Mess Detector, PHP Code Sniffer and others. All kinds of code that is only available at runtime is not available to static analysis and thereby prevents some features of these tools from working correctly. The most clear example is code executed through eval(), but also magic functions, objects loaded by passing the class as a string argument to a function or functions executed by hooks can make problems here. I think it makes a lot of sense to prioritize having a concise, human-friendly API over making the code well-consumable by static code analysis. Still it would be great to improve in this sector to benefit as much as possible from the existing tools in the PHP world.

Inputfield dependencies are evaluated by javascript only, that's why the api selectors do not work. The only information the dependency can evaluate are the values of the present form fields. It even does not work if a field is set to not editable, because in this case the value is not rendered as form field. The first impression of the form is after the first saveReady hook, as each page is created/saved right after you submitted the page name.

A module yes. But instead to hook into upload, you also can hook into page::save or page::saveReady I think. It depends upon how you have organized your site. Have those unity project pages an own template or not etc. Or do you only upload html files to those pages and not in others too. At least it will work this or that way. You will find many posts with example code here in the forums. One that hooks into upload / fileAdd is here. page::save is here and page::saveReady here. But there are lots more

Update: version 0.0.5 Fixed markup errors reported above in MarkupMenuBuilder Merged version to master (updated in modules directory as well)

Edit: It's actually a other line: https://github.com/ryancramerdesign/ProcessWire/blob/master/LICENSE.txt#L79

As I did a lot of performance optimization stuff for a client's website recently I thought I'll share some of my findings: - optimizing for "time to first byte": Apart from fixing performance issues with your php code there is an easy way to "get things started":Chunk your Output! Doing an ob_flush (or {% flush %} if you're using twig) here and there is an easy way to split your page into chunks that are instantly (and in parallel) served to the client instead of rendering the whole page at once. This is especially handy if you're using the next technique: - Inlining "above the fold" content I must admit that I'm not a big fan of inlining things. In my opinion it's against anything I've learned about keeping things "dry, clean and separated". That's why i refused to do it until now. But if you're using grunt/gulp (and especially criticalcss) you're not doubling anything and the inlining is just another task in your gruntfile. There is a pretty easy step by step guide by Jeremy Keith at https://adactio.com where he explains why inlining css on the first visit will gain your site a massive (perceived) performance boost on the first load (this is especially handy on mobile devices). I'll post a recipe to processwire-recipes.com how to achieve this with processwire in the next days - Avoid loading Webfonts directly but do it asynchronous as "Progressive Enhancement" (+ Store them in localstorage to load them super fast afterwards) to avoid blank pages: http://bdadam.com/blog/loading-webfonts-with-high-performance.html Just implementing these 3 (pretty easy) things made the pagespeed score climb up by 15 points and lowered the perceived loading time by at least 2 seconds below the "critical hurdle" of 1-2 seconds.

When you create the fieldset, it creates two fields. One is (fieldsetname) and one is (fieldsetname)_END. You put both of those in the template.

Issue was fixed by Ryan. $options = $fieldtypes->get('FieldtypeOptions')->getOptions('YOURFIELDNAME'); foreach($options as $option) { echo $option->id; echo $option->value; echo $option->title; } This output all your options (id, value or title). This piece of code doesnt work multilingual. It only outputs the default language. If you have a multilingual site you have to output value and title in the specific language. //get value and title in different languages; if ($user->language->name != 'default') { $title = "title{$user->language}"; $value = "value{$user->language}"; } else { $title = 'title'; $value = 'value'; } $options = $fieldtypes->get('FieldtypeOptions')->getOptions('YOURFIELDNAME'); foreach($options as $option) { echo $option->id; echo $option->$value; echo $option->$title; }; Hope this is useful for others!

I know there are benefits and drawbacks to different approaches, so I'll try to explain why PW uses the approach it does, and respond to some of the points above. The approach described as an alternative here is similar to what I've used on other projects, including PW1. I was really looking to come up with something different for PW2. The goal was to make it as absolutely simple as possible for people to add hooks and for people to make methods hookable. I wanted it to be in the background and everywhere, so that you really didn't even have to think about it. It's not designed for ease of consumption by xdebug, I'll give you that. But it is designed for ease of consumption by you and me, which I consider more important. Admittedly I don't use xdebug very much anymore, so designing things for xdebug has not been a priority. When you start a new CMS project, you are in a crowded space, so you have to come up with things that are different. So one of the ways ProcessWire differentiates itself is by making hooks easier to hook into and create than they are in other platforms, and I'd like to keep to that. When it comes to PW's code base, I consider it important to not add complexity purely for sake of static analysis. From my perspective, static analysis is a good thing, and I'm more than happy to let it dictate the direction of comments and what supports the code. But when it starts to dictate the direction of the actual code towards unnecessary complexity/verbosity, less efficiency or reduce the simplicity of the API, then I consider it no longer helpful. If ProcessWire were just a PHP framework and coders in IDEs were the primary audience, then I would feel differently. But for ProcessWire's audience and growth, when I'm confronted either making my IDE happy (and related tools like xdebug), or making the API (or related things like hook system) as simple and as good as they can be, I'm always going to choose what's best for PW's API and systems. My preference is making both happy. But when you are doing something different, existing tools won't always be familiar with it. For something like the hook system, there was definitely a conscious decision to go with what's best for PW and PW users, over what's best for static analysis or xdebug. All the add hook methods are actually handled by just one method: addHook(). The point of the other methods (mentioned below) is to make things simpler for you, and make your code more readable. I prefer verbose method names to boolean and array arguments because they are self describing. think this is a benefit, not a drawback. Use addHook() if you want to add a method to a class that isn't already there. Use addHookProperty() if you want to add a property (rather than a method) to a class. Use addHookBefore() if you want to hook before an existing method (and have the option of modifying arguments sent to it). Use addHookAfter() if you want to hook after an existing method (and have the option of modifying the return value). Regarding the distinction of hooking a class name or an object, this is also meant to be a help to you: The purpose of being able to call a hook on a class name is so that you can hook ALL instances of that class (current and future). The purpose of being able to call a hook on an object is to hook only that single instance of the object. As for ease of finding hooks, this is also something I've tried to make as simple as possible by using a convention that you won't see elsewhere in ProcessWire: 3 underscores prepended to a method. So while you can use CaptainHook, I'm not sure you need to, because you can find all hookable methods in ProcessWire simply by doing a search for 3 underscores "___". A recursive grep is one easy way to accomplish that. Page::render() is actually a very unique case that you won't see elsewhere in PW (that I can think of). Usually I would have just put a method like that directly in a class and have it handle the render from there (or have the method there to call up the PageRender module). But PW started out as fully API driven, where there was no such thing as "render" of anything, to the core. So the ability to "render" anything was seen as something specific to the web context of a CMS. That's ProcessWire now, but its roots are pure CMF. Today, I would likely just put that render() method directly in the Page class. But I also don't see any reason to move what's already working there, as it really makes no difference in how it works. And you can still hook Page::render if you want to, just like it actually did exist in the Page class. Because you can't actually see a Page::render() method in the class, we use phpdoc at the top of the file for it. I would love to make everything hookable, but the reality is that there is a little overhead associated with every hook (in any hook system). So I don't usually make methods hookable unless there is a request for it to be. We started with very few hooks, and now we have quite a lot. But the majority of the hookable methods you see in PW today are the result of people asking for them to be hookable. And luckily, it's very easy to do just that: just append 3 underscores, and you are done. I would answer this pretty much the same way as the Hookability point above. When more granularity is needed somewhere, we add it, and there's lots of examples throughout the core. But it's hard to know where one might need that until it is asked for somewhere specific. When a module like ProcessPageEdit was originally written, I honestly didn't know if anyone would ever want to hook anything in it at all. Over time, it has become more granular, and over more time will become even more so I'm sure, but only when specific needs for granularity/hooks come up. I love flexibility, but I also love efficiency. If everything in ProcessWire was fully granular and hookable PW might be very flexible for someone looking to hook specific things, but it would also be bloated and slow. My preference is to make specific things more granular and hookable when it will solve someone's specific need. Granted, there are plenty of hooks in PW already that nobody is using, but they are generally in places where it makes no difference in terms of efficiency. I'm not suggesting that hooks aren't efficient – there's very little overhead from hooks. It's just that if you multiply a very little overhead over thousands or hundreds of thousands of calls, then it becomes something. Are there any examples? I've tried to cover all potentially useful state changes with hooks, even if they aren't actively used. For instance, see the large set of hookable methods at the bottom of the Pages class. You'll see similarly named methods in any core class that deals with state changes (like Fields and Templates for example). Though it's also possible I've misunderstood what you mean.

As some of you might have noticed recently there has been a large "Frontend Performance Talks Offensive" (not only) by Google Engineers. Here are some high quality (regarding content) Videos which i enjoyed very much and thought you also might be interested in. A Rendering Performance Guide for Developers by Paul Lewis: Performance Tooling by Paul Irish Your browser is talking behind your back by Jake Archibald Gone In 60fps – Making A Site Jank-Free by Addy Osmani http://addyosmani.com/blog/making-a-site-jank-free/ Any suggestions for more interesting performance related stuff are welcome!

If you're not afraid of pirates, there's also the Table ProField: https://processwire.com/api/modules/profields/table/

Indeed, no hook, I hadn't read it through thoroughly enough and had assumed module = hook. And your solution is indeed less complicated, I think I'll replace mine by yours, it makes the code much easier to read

Thanks Soma, you're a genius!!! You're solution does not only work perfectly but it's also elegant and clean

Thank you for the quick responses! It does look like eAccelerator was the issue. It has been removed and replaced with APC and all is working well!

User language is tied to what language is requested. So it changes on runtime. User language set in admin is for backend primary. If you need user to set a language for frontend you could add a field to user and check that.

Pretty awesome at first sight, and on afterwards too. I like the colors and the "big" feel. The effects are bit too much (I know that's their wish ).

That error does seem to be related to eAccelerator. Looks like it doesn't support anonymous php functions (http://snippets.webaware.com.au/howto/eaccelerator-and-php-closures-dont-mix/) - there is one on that line in the SessionLoginThrottle module. I think you might have to disable eAccelerator. Maybe go with APC or Zend?

ProcessWire 2.5.21 dev

A refresh solved it. Thanks

The only thing which really depends on the server configuration is the RewriteBase. This is dependent on how php and the document roots are set up on the server. It does otherwise not matter to processwire in which folder it is or under which domain it's called.

What version are you running? It looks like one of the dev versions given that in master there is no attr call on line 1014. The error relates to the newish InputfieldIcon so I think maybe you have a version that had a bug where this wasn't installed when called. Running Modules > Refresh should sort it out. For reference, here are two Github issues about it: https://github.com/ryancramerdesign/ProcessWire/issues/891 https://github.com/ryancramerdesign/ProcessWire/issues/873 If you are running a dev version after this was meant to be fixed (which I suspect you might be based on the line number), can you please make a note on that Issue?

That's the case for the backend which ships with ProcessWire. The frontend is always custom and therefore there are no limitations in browser compatibility, but it depends on what the dev does build for you.

@tpr, Thanks. They are all part of the admin themes that natively ship with PW. In the first couple of screenshots, that's AdminThemeReno, followed by AdminThemeDefault using the color set 'Futura' and last screen the color set 'Warm'.

Can you please open an issue at https://github.com/r...micRoles/issues and reference this topic, so that any correction to the module can be made? Thanks

Very nice, a must-have. Thanks! May I ask what admin theme was used on the screenshots? Looks pretty sharp but cannot find anywhere.

- Fast search based on tags You mean in the admin area or the front end? In the back-end PW has a very fast search. On the front end (depending on your template setup), clicking a tag would bring up a list of matching pages with that tag. That's how I normally do it I'm speaking of tags invisible to the user which are only used for very quick frontend search results. Like the search box in the example page (which is extremely sluggish btw) - Download section to download user manuals I'll leave that to someone else. You'll need some registration and user verification around that? Nope, neither registration nor registration are needed. Just a page with links which start pdf downloads and some place in the backend to upload the sources. How fast can one realize all of this? Really depends on your skill levels. Are you new to CMS and PHP in general or are you pretty knowledgeable and just changing systems? I'm famliliar with content maintainance in Typo3 and HTML editing. But I only know PHP basics. I'm primarily java programmer. We are definately looking to outsource the job. But this will have to wait till the boss has decided on one CMS. I'm just gathering information What are the matters of expense, and what would the realization of that cost? (approximately) ProcessWire is open source. There are a few modules you may want to buy. if you're looking to outsource it, I'd recommend you look at the Jobs/Bounty forum and get quotes there. If we decide to use processwire, I will definately propose to look for someone here. I forgot to mention an aspect. Are there limitations in terms of browsercompatibility? Thank you very much for your comprehensive answer. Best regards Andrej Elbers PS: This site uses gravatar, I see...

The Title has been modified to reflect MobileDetect as the referenced module. Thanks for your prompt action on this issue.

@boundaryfunctions Regarding good IDE support I just want to mention that ProcessWire already has Phpdoc-Comments for most of its magic functions. At least in PhpStorm you get all the autocompletion if you tell your IDE which default variables are there. In templates where I want autocompletion I have a comment like this at the beginning of the file: // ============================================================================= // ProcessWire API Variables: /** @var $config Config */ /** @var $log WireLog */ /** @var $notices Notices */ /** @var $sanitizer Sanitizer */ /** @var $modules Modules */ /** @var $fieldtypes Fieldtypes */ /** @var $fields Fields */ /** @var $fieldgroups Fieldgroups */ /** @var $templates Templates */ /** @var $pages Pages */ /** @var $permissions Permissions */ /** @var $roles Roles */ /** @var $users Users */ /** @var $user User */ /** @var $session Session */ /** @var $input WireInput */ /** @var $languages Languages */ /** @var $page Page */ // ============================================================================= // Common used aliases: /** @var $p Page */ /** @var $img Pageimage */ And if you need autocompletion for your custom fields you can use the TemplateStubs module

In the famous "30 minutes" thread MadeMyDay somehow made a point by putting ProcessWire into context with TYPO3. Recently, I got an inquery for a multilingual website for a speaker agency. A customer looking for an Open Source solution. These speakers had meta data attached (topics, languages, speaking areas, gender) and this database would be the most essential part of the website. Also, a password protected area was needed where speakers could supply materials such as slides to an exclusive user group. Sounded like the perfect job for ProcessWire, unfortunately, after a while of internal consulting and decision-making, the customer chose TYPO3 instead. PW was totally new for them, they admitted to be fascinated by it, but went with the system they knew in the end. That, and Marc's above mentioned comment made me think. ProcessWire does a good job catering developers but still has room for improvement, in my opinion. Throughout the 30 Minutes / WP Tavern article I often read, "once the developers are on board, the rest will follow". I'm not so sure. It would not hurt to emphasize PW's abilities to serve as a business/enterprise CMS right now. Take the benefit teaser on typo3.org for example, a perfect intro. It states: Open Source Enterprise CMS Scalable Web Application Framework Large, active global community User friendly with unlimited extendability Integrated Development and Editing Workflows I guess most of these advantages do fit to ProcessWire as well or, in the case of continuous integration, are on the doorstep (at least that's how I read "Integrated Development"). And PW's community may not be large yet, but is damn active. Apart from that, the home page is full of, hm, let's say: trigger words that work on some business business owners: "enterprise", "professional", "web solutions" and "certificates". I'm not proposing to copy all this. But I have an idea: Since both TYPO3 and ProcessWire are relatively big here in Germany (each on their own scale) one could emphasize the "also a perfect business CMS" aspect on http://de.processwire.com. I guess this won't hurt "the brand" at all, but, possibly, create some insights on if and how such a communication strategy could work. /edit: These automated capitalized words in the thread title are really annoying :-/

This module stated that it is not compatible with PW2.5 but so far haven't seen any issue with ProcessWire 2.5.21 dev. I'm sure i'm not the only one using this module so updating the compatiblity with 2.5 looks fairly save to me. Thank for this awesome module.

Performancewise Chromium just beats Firefox. And it has a kiosk mode, too. From the cli "chromium --kiosk".

I had a similar experience and found that this happens when HannaCode renders a field which again contains some HannaCode. I submitted a patch to support recursive HannaCode to git. You could try out if it fixes your issue by replacing the TextformatterHannaCode.module file with the one in this fork: https://github.com/hwmaier/ProcessHannaCode/blob/master/TextformatterHannaCode.module

This would give you a pager without enabling PageNumbers on template, thus using /?page=2 instead of /page2 $pageNum = $input->get->page ? $input->get->page - 1 : 0; $limit = 5; $start = $pageNum * $limit; $result = $page->children("start=$start, limit=$limit"); echo $result->renderPager(); foreach($result as $p) echo "<p>$p->url</p>"; echo $result->renderPager();

Greetings Larry, Excellent discussion! Coming from the world of PHP frameworks, I am also very curious about the most "MVCish" way of working in ProcessWire. An interesting challenge is that a lot of the "M" and "C" necessities in frameworks are handled differently (I would say better) in ProcessWire. And yet, as we develop more complex sites, the templates can get quite involved with material that properly should be abstracted into some sort of classes/functions/controllers. What's great about ProcessWire is that we have the best aspects of frameworks, with the freedom to be creative in how we structure views and functions/classes, and it takes care of many crucial database elements in efficient ways. We then have the potential to develop interesting structures, without being forced to worry about too many conventions. I'd love to see a discussion here where we share creative ideas for structuring ProcessWire sites in MVC ways. Thanks, Matthew