ryan

I think I understand what you mean now. No problem--I'll move the definition of that text into the __construct so that they can be translated.

Good points Pete. Admittedly, the way that Form Builder is built is really more about being platform independent than anything about the GPL. I had thought I might get Form Builder running on another CMS like WP or EE. I thought this would increase the audience size and increase visibility of ProcessWire. I don't think I'll end up doing that, but just wanted to have it ready for it. I don't think that other people's future commercial modules need to take that approach unless they want to.

Admittedly I don't use a treeMenu type function all that often myself. I think it just depends on the sites you are building. But I really like the solutions you've mentioned here--very elegant. Perhaps we should have some kind of visit() function like this in the core. Though unless it would be something most people would use, it may belong as a module or library. I'd be curious what other people think. Btw, I thought you might like the planned roadmap for ProcessWire 2.4. I'm hoping to finally get started on the full transition to PHP 5.3 here in the next couple of weeks, after PW 2.3 is final. I'm also going to try and get that alternate module configuration method in there for you, if you don't beat me to it.

The ImageSelect module doesn't actually let you upload images. It just lets you browse, select, and resize them. It's not very useful outside of the TinyMCE context, though the plan is that we'll make it work with other editors as we add them. But because it's designed as something to be used from the Page editor, that's why the base permission for it is page-edit. The actual upload capability comes from the InputfieldFile module.

You guys probably already know this, but those permissions assigned at the template level are inherited through the page tree unless you choose "Yes" for defines access in your template settings. Meaning, you only have to define access on templates where you want to change something about the access. For example, lets say you've got a /members/ page that requires a login. You would define access for the template used by the /members/ page. But you wouldn't need to define it on any other templates used on pages below that. Meaning the templates used by /members/cool-stuff/ and /members/great/content/ do not need to define access, because they inherit it from /members/. This is a simple example, but the same rule applies for page editing permissions and such.

Good news, we actually have a working version of the module. When I woke up this morning, I got an email from Horst -- he had built the libraries and had them ready to go. With those, I was able to build most of the rest of it today. We'll probably send it back and forth once or twice to test, and then we'll post a version 1.0 hopefully within the next day or two here!

It does seem to be open to some interpretation. The intention is definitely to avoid the interpretation of platforms like WordPress because it seems to have contributed to a very low quality-to-quantity ratio of plugins. It's also segmented their customer base as there are plenty of commercial themes and plugins, but operating off on their own. Though we are a very different tool from WordPress, and I can understand why the WordPress folks interpret it that way in their context… but again the underlying purpose of ProcessWire is different from WordPress. With ProcessWire, I want to support the entire community and am hoping that in the long run this helps us maintain a stronger community and higher level of quality than there is with WordPress. Though don't get me wrong, I do respect a lot about WordPress and it's leadership and the way they've been able to grow. I like the MIT license, but didn't go with it just because I was concerned that others might take ProcessWire and turn it into a commercial project or somebody might start selling ProcessWire under another name. A couple years later now, I'm less concerned about that. Mainly I just want to provide what's best for the users, and I think GNU does that. But I do think it requires understanding what ProcessWire is and isn't. I don't see grey area myself. But if others do and it prevents people from using ProcessWire, then I would consider a more open license like MIT. That's assuming you would consider it for your work with InputfieldFile. You are technically our biggest core contributor.

I appreciate your concern, and I'll try my best to clarify. I'm the copyright owner of all code used in these modules (FormBuilder, ProCache). I'm also the copyright owner of the module interfaces and the ProcessWire core. I make a point not to rely on any code I've not written personally or that other people have contributed to. But I think you are looking for clarification on a bigger picture, so I'll instead focus on others that might want to create stuff in ProcessWire. We do not require that all websites and modules produced on top of ProcessWire's framework be free, and I don't know of any tool like PW that does. What I don't want people to be able to do is turn ProcessWire itself into a commercial product or be able to change ProcessWire's license. But I do want them to be able to use ProcessWire in the manner it was intended. ProcessWire is intended and built as a platform to manage and execute modules. I do not support extending ProcessWire itself with anything but GPL v2, but I do support ProcessWire being used as the tool it was meant for, without restriction. Years ago, in talking with other CMS developers for projects much bigger than ProcessWire, they'd suggested to use GPL v2 but make clear that the project encourages and supports an ecosystem that is not against commercial modules (which I've done on several occasions), so that there is no grey area. In fact, ProcessWire's API and architecture reflects this intention. When you build a site or module on top of ProcessWire, you are not extending ProcessWire--you are using it as a tool for exactly what it was designed for. For the sake of our users, I want to be clear that I consider a module running on ProcessWire no different than a website running on ProcessWire–they use the same API and in the same way. This architecture is intentional. And I certainly don't want people to think that their own websites, content, images, assets, etc. are GPL as a result of running on or being delivered by ProcessWire. For others making commercial modules, I am also okay with fees charged for 3rd party modules to be support/service/distribution fees rather than license fees (which is the route I like, though wouldn't require it). I don't support any kind of obfuscation though, and wouldn't list obfuscated modules in our directory. I need to be able to confirm that something is coded with attention towards security before I'd list it in our directory.

While you can change those directory names in index.php, it's not something that ProcessWire is designed to support. I also don't recommend trying to change them just because it would introduce potential security problems, as the htaccess file is focused on blocking certain directories and access while allowing others. Also, this would make it difficult for you to upgrade ProcessWire, since your directory structure would be different from the source. Lastly, many files in /wire/ actually need to be http accessible, like the css and js files that are used by modules. So /wire/ must web web accessible.

Yes, I think I replied in that other thread that I'll add that. Most likely in 2.4

You can see it if you click "filter > show system templates". There's a reason why it's hidden as a system template though, so it's not good to change the settings of a repeater template. A template is a data type. A template-file is a file, related to the data type. If you delete the template-file, it doesn't delete the template. Those are called "ready pages". If you don't want it to keep ready pages, you can set the ready pages to "0" in the your repeater field's settings.

That was never meant to be used on the front end. I'm impressed you actually got it to work. That module really does need to bind itself to page-edit permission just for the security of the admin. But what you might want to do is copy that modules files to your own dir in /site/modules/ and rename them, and rename the class to something like ProcessPageEditImageSelectCustom. From there, you can modify it to do what you need.

I agree with Joss that repeater sounds about right for what you've mentioned. But if you need infinite scalability, I'd suggest creating a new template to represent your data table, and then make each entry of it a page.

Not sure that I understand. Date modified is not the default sort order. The default sort order is manual, which naturally looks like 'date created' order, until you drag a page in it to a different order. The default sort order for a page's children can be specified either at the page level or template level. If specified at the template level, you won't see the option at the page level.

Currently the CommentsManager is available to users with 'page-edit' permission. I'll add some custom permissions for the next version of this. But if you want to change the behavior now, edit the ProcessLatestComments.module file and change this line (near the top): 'permission' => 'page-edit', to this: 'permission' => 'comments-edit', Then go to Admin > Access > Permissions, and add a new permission named 'comments-edit'. Then assign this to any roles you want to have access to it. If you only want it to be superuser, then you don't need to assign it to any roles.

I may be the starter of the project but there are lots of team members here. ProcessWire is everyone's project. We probably need to highlight that more on the site. You don't see collaborators in the GitHub tree simply because of the current workflow--I don't [yet] use GitHub to merge pull requests directly. As a result, collaborators don't show up in that tree, but are always highlighted in the commit notes. Regarding PHP compatibility: ProcessWire is already compatible with PHP 5.4. It's unlikely that newer versions of PHP would break ProcessWire, but if for some reason it did, we'd update it. We will soon be dropping support for PHP 5.2, so that we can take advantage of what PHP 5.3+ offers.

Also want to add that it's a pretty simple matter to take a theme (like a WordPress theme) and adapt it to ProcessWire.

For anyone else following this thread, Horst and I are collaborating on building a module for this, but the discussion moved to email.

Hehe, no magic here. Maybe you have a magic computer?

O'Reilly is having a pretty good e-book sale on PHP books: http://shop.oreilly.com/category/deals/php-owo.do?code=WKPHP

it is valid. Though you could also just specify $template (without the ->name). Any calls to a function that returns a PageArray (like $page->children(), $pages->find(), etc.) are going to exclude pages that are hidden, unpublished or otherwise inaccessible to the user. To make it include them, you can specify one of these: include=hidden -- includes hidden pages. check_access=0 -- Includes pages the user doesn't have view access, as a result of role permissions. include=all -- includes all pages with no restrictions.

This is a setting I don't use very often, as I find it kind of a pain. But others here like Soma are experts with it. If you search for TinyMCE and "styleselect" (one word) it should turn up some information on it. Here is another link that might be hepful: http://wiki.processwire.com/index.php/TinyMCE#Adding_Styles Basically, you create your own css file for TinyMCE and place it somewhere like /site/tinymce/custom.css. Then you edit your field, click on the "input" tab and open the fieldset for "TinyMCE custom/advanced settings". From there, you can specify a link to your custom css file. You would then add the styleselect option to your buttons. Also look into the Bramus CSS Extras TinyMCE plugin, which is mentioned in these forums often, as it improves what you can do here quite a bit .

You could go with simple text replacement. Lets say you wanted the icons in the body (though it wouldn't matter what field). You'd just instruct the client to visit this page and select the icon they want. That page shows both the icon and the name. You would have them copy the name and then paste it into their copy, wherever they wanted it to appear. Then in your template code, you'd run $page->body through something like this before outputting it: if(strpos($page->body, 'icon-') !== false) { $page->body = preg_replace('/\b(icon-[-a-z]+)\b', '<i class="$1"></i>', $page->body); } So if the client typed this: They'd get this in the markup (which would display the relevant icons): This would be another case where you could use simple text replacement before output: $page->body = str_replace("<h3>", "<h3 class='someclass'>", $page->body); Though if you needed to support different kinds of h3 tags or classes in that copy, then you'd probably want to use TinyMCE advanced settings to setup the 'styleselect' option. This would also be a good option: just targeting those specific h3's with a CSS selector. I think I'm going to go grab some icon-coffee.

You are basically getting the date of value "0". Double check that the timezone is a valid one. Double check that the field you are viewing has a value. Try entering it again.

We do provide hooks for adding any kind of additional server-side validation. But like Soma mentioned, the HTML5 pattern option may be adequate for typical admin input. While not present as an option on any fieldtypes at present, it is pretty easy to add directly in the DB. And I've left it that way just because the need is so rare, and easy to do when/if needed. You can just add a 'unique' index to the 'data' field in any field_* table. A good example: ALTER TABLE field_email ADD UNIQUE data_unique (data); I'm not 100% sure what you mean, so I'll cover a few possible answers: You can relate pages using the 'Page' fieldtype You can group two or more fields using the 'fieldset' or 'tab' fieldtypes You can concatenate the values of two or more fields using the 'concat' fieldtype This is what hooks are for (again, as already mentioned by Soma). Lots of fun possibilities here. Just let us know if you need help setting one up.