Leaderboard

This module extends the FileValidatorModule to provide the ability to validate and sanitize SVG files. http://modules.processwire.com/modules/file-validator-svg-sanitizer/ https://github.com/adrianbj/FileValidatorSvgSanitizer If you're interested, here is some reading on why this is important: http://www.ei.rub.de/media/hgi/veroeffentlichungen/2011/10/19/svgSecurity-ccs11.pdf https://www.hackinparis.com/slides/hip2k11/09-TheForbiddenImage.pdf Have a read about about the new validator and the SVG sanitizer in Ryan's blog post.

Today we launched one more website. Plana Press is a small illustration books publisher from Porto. http://planapress.org/ This site is very simple, nothing special technically besides the fact that the initial image changes randomly with different sessions. Also the link underlining color follows the color of that same image. You won't see these differences during the visit to the site, so I'm sharing the way I used to check all the images and colors during development: add ?v=1 to ?v=9 to the end of the homepage url to see all variations: http://planapress.org/?v=1 ... http://planapress.org/?v=9 -- In 2010 they published a book with some sketches of mine. See it here http://planapress.org/livros/big-hands-small-mobile/

When it comes to security, one important thing to note is that Ryan has taken a very strict approach to that in ProcessWire. Our codebase is clean (free of unnecessary clutter and legacy stuff), attempts are made to mitigate known attack patterns, and strict filtering is applied before requests even reach the system itself in order to protect it from possible future attacks. ProcessWire 2.x may have it's roots in much older systems, but it's also a complete rewrite, built from the ground up for it's current design philosophy and set of features. Not having a huge user base isn't the most important factor when it comes to the amount of existing/found vulnerabilities, even if some folks out there like to claim so. There's a lot more to software development than that, and the truth is that not all software is born equal. In some ways it's actually unfair to compare ProcessWire with some of the older projects out there. Not only did some of them start out as something entirely different and just grow organically (and without much planning) to what they are now, they've also got a lot of legacy payload under the hood. By legacy stuff I mean features they can't remove in fear of breaking backwards compatibility and/or can't rewrite because it'd be an enormous task. It's true that we're still relatively young, small, and agile, and for the most part simply don't suffer from those issues.. but it also looks like we might be able to keep this up for a very long time. Some of the key factors here are not leaning too much on the idea of "never break backwards compatibility", making the right architectural choices (API design, etc.) and honing our development process all the time. As a side note, regarding ProcessWire modules, the quality of those is pretty good too. The amount of 3rd party module authors is still limited, and so far we've been able to, more or less, go through each new module submission and make sure it's quality is acceptable. If we had tens of thousands of modules, that'd be pretty hard to pull out, I'll give you that.

Maybe we need to make "Search ProcessWire" a part of the documentation

The only security vulnerability I can remember was in my own Minify module (not to be confused with AIOM) as it relied on this library: https://code.google.com/p/minify/ however as soon as I was made aware of that it was patched and updated. I can only echo what others have said above - you can never say with 100% certainty that there won't be a security issue discovered in software of this size, especially when coupled with all of the possible web server platforms and server module combinations. There are too many variables for anyone to say with certainty on any project that a security issue won't be found. There is more likely to be issues arising from our own code (not sanitising user input etc) than in the core though (that's my own experience anyway). The default templates even with search capability (user input right there) are build with best-practises in mind and offer several different ways you might want to build your front-end, but it's usually when you start doing your front-end work that you have to be careful - obviously PW is one of those rare projects where you don't need to upgrade a site if it works. If there were to be a vulnerability discovered, I would wager that you would have an easier time upgrading than with many other projects though (your front-end templates just won't instantly break for one because the API calls all remain the same!). I have been, for the last almost 4 years (wow, that's flown by) pleasantly surprised by the lack of a need to keep things up to date. I've never used Wordpress for my own sites so haven't suffered that rapid upgrade cycle, but have used MODx where every so often I've had to patch multiple sites. Now pretty much everything is on ProcessWire for me I've not had to do any of that. Choosing when to upgrade based on new features that might benefit the client, or might enable me to sell additional services to the client - that is the position we should all be in, not dropping everything to upgrade every couple of months But yes, the final line on security should be that none of us can say that a security issue will never arise, just check your module compatibility when upgrading (and it's best to test those modules locally as well because I think most will work on newer versions even if the module pages in the directory haven't been updated) and you should be fine.

Please do first look at the Edit part. I seems like the script adds the alternative "0" as value for unchecked checkboxes to the checked ones as well. Could you please add the consoleLog statement in the inputfields.js: if(($field.attr('type') == 'checkbox' || $field.attr('type') == 'radio') && !$field.is(":checked")) { // @todo this part will no longer work with multi-checkbox/radio fields consoleLog("*** Added 0 as alternative ***"); values[1] = '0'; } If this prints the line for both unchecked and checked states than we at least know where it's not working correctly. Edit: Looking at your logs again, maybe this isn't the issue, but more likely the checkbox returning a value of 1 even if it's unchecked. Could you also please test if this lines are correctly setting value to null. // value of the dependency field we are checking (if not already populated above) if (value === null) { if($field.attr('type') == 'checkbox') { value = $field.is(":checked") ? $field.val() : null; } else { value = $field.val(); } }

To make this fully clear. The implode function you're using is a ProcessWire specific implementation of the php function. The php version does only work on arrays and the array has to be passed into the function as parameter. What you're using is a method of the WireArray class, which mimics a lot of the array features, but adds lot more to it. That's why the syntax is different and therefore the php docs wouldn't help to much.

Similar here, for info https://processwire.com/talk/topic/6196-easy-search-on-pw-forums-with-google/ My favourite though: https://cse.google.com/cse/publicurl?cx=014789015761400632609:fxrf0rj4wr4

This is the organization we've put in place at work. The structure is pretty much fixed now, we're still grabbing parts of things we like elsewhere. It's basically a bootstrap kit. Workflow goes at this : 1) clone latest pw and setup project with https://github.com/plauclair/pwscripts 2) clone our site profile 3) remove extra, configure grid or else from less mixins, select which layout to use and import html presets that match these 4) marvel at all the time saved 5) code 6) ?? 7) happy customers, happy devs! templates/ |-- styles/ | |-- styles.less // general styles, calls parts in inc/ | |-- styles.css // compiled from styles.less | |-- inc/ | | |-- layout-one-pager.less // standard layouts | | |-- layout-standard.less | | |-- content.less // regular h1, p, ul, etc.. | | |-- template-name.less // each template has its own less file | | |-- template-...less | | |-- vendor/ // decoupled parts from different frameworks | | |-- bootstrap/ | | |-- grid.less // decoupled grid system, generator w settings | |-- images/ // images called from css | | |-- scripts/ | |-- main.js // main js stuff for global things | |-- vendor/ | |-- vendor-name/ | |-- files... | | |— inc/ // php includes, has ready-made classes like a recursive menu generator and other helpers |-- views, controllers, classes, etc../ // depends on the project's complexity | |-- _header.php | _init.php // config->prepend |-- template-name.php // typical PW template files |-- template-...php

The other tool to add to your belt is ModulesMigrator: https://processwire.com/talk/topic/8410-modules-migratorinstaller/ It will install, configure settings, and update to the latest versions all modules that you have selected. I have tagged it as alpha, but mostly because I haven't had any feedback on it. Maybe if this brings it back to life and I get some reports on it, I can get it released - it really is pretty straight-forward.

Just caught up on this thread. I think you are all several steps ahead of me on this but I'd like to help. Documentation matters. I like what's been said about automated docs and streamlining that process (apigen, webhooks, etc.). I like that people are recognizing how useful different types of docs are.. Some observations: JQuery docs site is pretty good as a quick reference for syntax, methods, etc. and has good simple examples nearby. The PHP docs have always been a pretty good function reference (and there are so many!). How they handle comments is interesting. There are good and bad comments but it's great having them, especially for quirky version specific and environment specific stuff. Over they years they've tried various ways to organize and filter that content. Currently they have up/down voting but that has the effect of pulling posts responding to earlier posts out of their context, making them somewhat ambiguous. I'm particularly keen on using a PW web site to tie things together (eating our own dogfood). I'm just spewing coffee fueled ideas here, don't be too harsh, but somehow we should be able to use automatically managed tags, categories, etc to facilitate jumping around between tracing through code in apigen, seeing relevant "recipes", locating relevant posts (some curating and crowd sourced up/down voting here), Github issues and updates, etc. I'm imagining some kind of all-knowing sidebar navigation generated by PW and with AJAX, RSS and minimal intrusion could be be tacked on to things like the cheat sheet, apigen, this forum, etc.

Try this in the 'custom php code input' $author = wire('user')->id; return $pages->find("template=server, created_users_id=$author");

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

How can we show only the default language field for a certain role and hide the rest of the input options? I'm thinking PageTitleLanguage specifically.

In answer to my own question I came up with a solution using good old jQuery and the Service Pages module. Use it to choose any node in a tree that ServicePages will let you access. Here's a quick video of it in action: Demo (.avi) Could use hover to reveal the selects but that won't help people on touch screens. The PW pages used here are like you find in typical PW category schemes, just the default fields. Reasonable conventions for ids and classes so no problem using more than one at a time and styling them alike or differently.

Maybe have a look at the chmod of the php files. This could be an issue as you say other files work.

Would it be useful to any other module authors if there were some way of notifying a module that it had just been updated? So, when you do a module update in the core, to have an OnVersionChange($old, $new) method (or something else that hits the mark) in the base class that the core then calls. Modules could override the implementation to provide whatever udpate to their schemas they need? I know that some of Teppo's modules track their version numbers so they can detect changes and update their table schemas as needed but it seems to me that this would make a pretty good core-feature candidate. I've just had a most welcome pull request on one of my older modules but it will require me to manually add my own module version checking/schema update mechanism to handle things nicely (probably just a copy of the way Teppo does it) but I'd rather not do that if we can get something into the core that does it well.

Bump... Added this as a github issue.

Isn't it available in the Client area ? Top right of forums...click your profile name.

This code doesnt add anything to the log files (wheter checked or unchecked). This piece of code solves my problem. Now checkbox fields work as expected as dependency field! Thank you so much for your effort!!!!! From now on you are no longer LostKobrakai - you are BestKobrakai Best regards Jürgen

Here is the problem: Field snintegration - Current value: 1 inputfi...s?v=13c (Zeile 20) Field snintegration - Matched? YES inputfi...s?v=13c (Zeile 20) Field snintegration - Current value: 0 inputfi...s?v=13c (Zeile 20) Field snintegration - Matched? NO inputfi...s?v=13c (Zeile 20) ---- inputfi...s?v=13c (Zeile 20) Determined that field "facebookaktivation" should be visible. inputfi...s?v=13c (Zeile 20) Field is already visible. The field is always visible independent if the value matches or not!!!!!! This only happens if I choose the value "1" as condition - with the value "0" it works as expected.

This is from the console: Checkbox is checked: JqueryC...s?v=183 (Zeile 2) ------------------------------------------------------------------- inputfi...s?v=13c (Zeile 20) Field "socialnetworksintro" detected a change to a dependency field! Beginning dependency checks... inputfi...s?v=13c (Zeile 20) ---- inputfi...s?v=13c (Zeile 20) Start Dependency 0 inputfi...s?v=13c (Zeile 20) Condition type: show inputfi...s?v=13c (Zeile 20) Field: socialnetworkactivation inputfi...s?v=13c (Zeile 20) Operator: = inputfi...s?v=13c (Zeile 20) Required value: 1 inputfi...s?v=13c (Zeile 20) Field socialnetworkactivation - Current value: 1 inputfi...s?v=13c (Zeile 20) Field socialnetworkactivation - Matched? YES inputfi...s?v=13c (Zeile 20) ---- inputfi...s?v=13c (Zeile 20) Determined that field "socialnetworksintro" should be visible. inputfi...s?v=13c (Zeile 20) Field is already visible. inputfi...s?v=13c (Zeile 20) ------------------------------------------------------------------- inputfi...s?v=13c (Zeile 20) Field "Inputfield_fieldset1" detected a change to a dependency field! Beginning dependency checks... inputfi...s?v=13c (Zeile 20) ---- inputfi...s?v=13c (Zeile 20) Start Dependency 0 inputfi...s?v=13c (Zeile 20) Condition type: show inputfi...s?v=13c (Zeile 20) Field: socialnetworkactivation inputfi...s?v=13c (Zeile 20) Operator: = inputfi...s?v=13c (Zeile 20) Required value: 0 inputfi...s?v=13c (Zeile 20) Field socialnetworkactivation - Current value: 1 inputfi...s?v=13c (Zeile 20) Field socialnetworkactivation - Matched? NO inputfi...s?v=13c (Zeile 20) ---- inputfi...s?v=13c (Zeile 20) Determined that field "Inputfield_fieldset1" should be hidden. inputfi...s?v=13c (Zeile 20) Field is now hidden. inputfi...s?v=13c (Zeile 20) 1 visibility changes were made. inputfi...s?v=13c (Zeile 20) InputfieldWindowResizeActions() Checkbox is not checked: JqueryC...s?v=183 (Zeile 2) ------------------------------------------------------------------- inputfi...s?v=13c (Zeile 20) Field "socialnetworksintro" detected a change to a dependency field! Beginning dependency checks... inputfi...s?v=13c (Zeile 20) ---- inputfi...s?v=13c (Zeile 20) Start Dependency 0 inputfi...s?v=13c (Zeile 20) Condition type: show inputfi...s?v=13c (Zeile 20) Field: socialnetworkactivation inputfi...s?v=13c (Zeile 20) Operator: = inputfi...s?v=13c (Zeile 20) Required value: 1 inputfi...s?v=13c (Zeile 20) Field socialnetworkactivation - Current value: 1 inputfi...s?v=13c (Zeile 20) Field socialnetworkactivation - Matched? YES inputfi...s?v=13c (Zeile 20) Field socialnetworkactivation - Current value: 0 inputfi...s?v=13c (Zeile 20) Field socialnetworkactivation - Matched? NO inputfi...s?v=13c (Zeile 20) ---- inputfi...s?v=13c (Zeile 20) Determined that field "socialnetworksintro" should be visible. inputfi...s?v=13c (Zeile 20) Field is already visible. inputfi...s?v=13c (Zeile 20) ------------------------------------------------------------------- inputfi...s?v=13c (Zeile 20) Field "Inputfield_fieldset1" detected a change to a dependency field! Beginning dependency checks... inputfi...s?v=13c (Zeile 20) ---- inputfi...s?v=13c (Zeile 20) Start Dependency 0 inputfi...s?v=13c (Zeile 20) Condition type: show inputfi...s?v=13c (Zeile 20) Field: socialnetworkactivation inputfi...s?v=13c (Zeile 20) Operator: = inputfi...s?v=13c (Zeile 20) Required value: 0 inputfi...s?v=13c (Zeile 20) Field socialnetworkactivation - Current value: 1 inputfi...s?v=13c (Zeile 20) Field socialnetworkactivation - Matched? NO inputfi...s?v=13c (Zeile 20) Field socialnetworkactivation - Current value: 0 inputfi...s?v=13c (Zeile 20) Field socialnetworkactivation - Matched? YES inputfi...s?v=13c (Zeile 20) ---- inputfi...s?v=13c (Zeile 20) Determined that field "Inputfield_fieldset1" should be visible. inputfi...s?v=13c (Zeile 20) Field is now visible. inputfi...s?v=13c (Zeile 20) 1 visibility changes were made.

Then please to to /wire/templates-admin/scripts/inputfields.js and enable DebugMode on top there. Also make sure debug mode in /site/config.php is enabled. This will print out lots of information about the dependency management in your console. If this does not help by itself please post the relevant parts here.

hmm, in Firefox 37 on Windows 7 there's no background image, only white? With Chrome it's ok.

Maybe this could help you debugging. $mr = wire('user')->user_mr; $p = new Page(); $p->template = "basic-page"; $p->parent = $pages->get("/"); $p->title = $mr; // See what value $mr has // $p->title = $mr == "4702" ? "Is 4702" : "Is not 4702"; // alternative $pa = new PageArray(); $pa->import($p); return $pa;

Something I like to use myself Create a bookmark and set the url to: javascript:void(q=prompt('ProcessWire.com Search:',getSelection()));if(q) void(window.open('http://google.com/search?q=site:processwire.com '+encodeURIComponent(q))) Enjoy!

Thx for this Adrian. Would it be able to work with custom tabs?

@diogo- check your code.. <a class="home-link" href="/"><img src="/site-plana/templates/styles/images/plana.png"?></a> the extra ? is causing FF to not load that image

Because Processwire sometimes feels like chill out on web

We're using a pretty opinionated yeoman generator somewhat similar (but different... i.e. no coffescript ) to the one from fixate. It's more or less like fireshell. The generator pulls a fresh copy of processwire + evergreen modules, sets up the directory structures, downloads npm & bower modules and creates basic templates + includes that we need for most of our projects. For the database part we're currently planig to integrate wireshell as soon as it leaves the beta status.

Just to echo what's already been said, the site profile option works great. I have my own "blank slate" profile, which really just has a few baseline things setup.

I do always start from a blank state as I'm not using any frameworks consistently throughout multiple frameworks. But siteprofiles are an easy way to save an own baseline, which can be installed by pw, so no copy pasting and replacing things in the database by hand.

I am curious if you're thinking on a page basis, or a template basis. I like the idea of adding this option, but I don't want to overcomplicate - it could turn out to be quite a matrix of options if you wanted certain pages/templates for some roles, but different ones for other roles. I think this is quite do-able a might be a nice addition to this module. I think I'll add this functionality, but I would also like to have the option of adding an Unpublish button to the Content tab if the Settings tab is hidden because I am also in the same situation that in almost all cases, the Status section is the only part of Settings that I normally want most site editors to see, but rarely is Hidden necessary for them. It seems like an extra complication to have the Settings tab at all for many user roles, but of course the publication status sometimes still important.