teppo

Take a look at Hanna Code module, it does exactly what you described above.

@dazzyweb: no-one can revoke the license on copies already distributed under GPL, that'd be impossible, but the copyright owner can always distribute more copies, with different licenses each. That's what multilicensing is all about. .. and yes, it does sound kind of like a technicality, but that's how copyright law works. License is something that the developer uses to grant users permission to use his work, not something he is bound by himself. Ryan doesn't need a license to use ProcessWire, copyright grants him that permission already

@Pete: you're absolutely right there. A court probably wouldn't argue against copyright holders intentions especially considering that if someone "violated" the terms set by ProcessWire's GPL license, i.e. didn't adhere to the requirements set by said license, then the license wouldn't apply to them and they'd actually be violating Ryan's rights as the copyright owner.. and only Ryan could sue them for that . See where I'm going with this? To summarize this, if you want to extend / modify and then distribute a copy of ProcessWire that's licensed under GPL, you must follow the rules set by that particular license. Otherwise the license wouldn't apply to you and you'd in turn be violating Ryan's rights as the copyright owner.. which wouldn't make any difference unless he decides to sue you for that. On the other hand, if Ryan ever decides that he wants to provide you with a copy of ProcessWire under another license (and as the copyright owner that should be well within his rights, though I'm not a lawyer and might be wrong here), you can modify that copy without having to consider rules set by GPL. This Stack Overflow answer pretty much summarizes it all. Highly recommended! Edit: this is getting pretty far from the original subject, which was commercial modules. I think that we've just about reached the conclusion that yes, you can create commercial modules, and no, you probably won't get sued for that. Since this seems to be a relatively common subject here these days, perhaps it would make sense to add some kind of short explanation to the website, maybe to About > Licensing section?

Yeah, used it for a jQuery plugin a while ago. Can't get much more "permissive" than that.. There's a license for pretty much every specific need out there, but for a system like ProcessWire I believe GPL was good choice. At least we, it's users, know it'll stay free (as in freedom, but probably as in beer too.)

It's a fact that you cannot (legally) combine GPL code with code under any non-compatible licenses. That'd be a violation against GPL and most likely against the other license too. Ryan's explanation (here) is based on his interpretation of what extending / building on another application really means; as he explains it, he doesn't consider 3rd party modules to extend ProcessWire -- they just use an API it provides. I would argue that this is a legal grey area and no-one really knows for 100% sure how these rules work or what's legally considered "extending". Even the code word "extends" doesn't necessarily imply that this is something that in legal sense "extends or modifies" ProcessWire and thus needs to be published under GPL (or not be published at all). Heck, even FSF, though they (or mr. Stallman of FSF) are the authors of GPL license itself, admit that they don't know for sure how this would be interpreted in a court: So, I guess it's ultimately a question of whether ProcessWire modules are "intimate enough" with ProcessWire core to make a single, modified program vs. running as separate, individual programs that just communicate with each other. Personally I'd trust Ryan's judgement on this, as it seems to make sense. What I would like to point out, though, is that legally it doesn't make any difference what anyone here, including Ryan, has to say about this -- what really matters is the copyright law and how it should / would be interpreted. In any case I don't think that anyone is going to sue you for creating a commercial module with closed license.. @dazzyweb: regarding FB and ProCache licenses, see this post by Ryan. AFAIK this applies to both modules.

There's a closed issue related to this at GitHub; magnific popup has replaced fancybox in dev branch. This issue has also been mentioned here before. On a mobile so I can't link to related posts right now.. try Google search if forum search returns nothing useful

@Manol: might want to check this GitHub issue out. Looks like something somewhere has changed and all 3rd party admin themes may not be entirely up to date, possibly related to your issues here. By the way, have you made sure that you're running latest version of Futura?

@lundy: congratulations, you've nailed it. That's a very good way to describe it Of course it's not literally quite like that. Since you've mentioned that you're a beginner, it might be useful to know that there's a lot more happening behind the scenes: Each page is connected to a template, which is connected to a fieldgroup and each fieldgroup is connected to varying number of fields. Taking things even further, each page is represented as a row in pages table, each template as a row in templates table, each fieldgroup as a row in fieldgroups table, each field as a row in fields table and so on. Eventually each row of data you've filled on any of your pages inserts a row in that particular field's own database table, i.e. field_title, where column pages_id identifies the page this particular row is related to and column data contains actual title field content for that page. Field tables can have varying amount of different columns, but this is the basic setup anyway. Understanding how things are connected at database level IMHO makes them more obvious on the front end side, but for most use cases (and most users) knowing what you already know is quite enough. It's still good to realize that there's a lot more to a system like this than just simple database table with couple of columns and rows Each question as it's own page does seem the most obvious solution here. Of course this still depends a lot on your specific needs; are these questions just simple question-answer type of things, how much data is there going to be for each of them, do they have comments or votes etc. Ryan recently published an events field, which could also easily be modified to accommodate very simple question-answer-pairs.

@pwired: if you want to create your own starting point, take a look at http://modules.processwire.com/modules/process-export-profile/. ProcessWire blank profile already mentioned above is available at http://modules.processwire.com/categories/site-profile/ (among other options).

Hi! On a bit of a rush here, just some short answers: Yes. PageArray, when treated as a string, should look like that. See PageArray->toString() for more details. You can access specific items with $pagearray->eq(0), $pagearray->eq(1), $pagearray->first(), $pagearray->last() etc. or iterate it with foreach. Through API or via admin UI? Both should be doable, admin UI has "copy" link and http://cheatsheet.processwire.com/ provides details for API side (tip: look for "clone" method from Pages or PageArrays.) No, created date tells when page was created, i.e. added

@Ryan: not sure if you've included that in your version, but you might also want to avoid minifying content within pre tags. Personally I'd also leave script tags alone. The minifying solution I used as basis for example code in my hooks blog post didn't originally account for that, which is why it blew my site apart under certain specific conditions. Could've avoided this by altering embedded scripts, but it felt safer to simply skip them. If I really wanted to minify JS, I'd rather use a service built for that -- better results, fewer issues