ryan

Just want to mention that this: $theseones = $pages->get( "/" )->find( "has_parent=/, tag_seasons=/tags/seasons/spring" ); is identical to this: $theseones = $pages->find( "tag_seasons=/tags/seasons/spring" ); So there isn't any reason to have a $pages->get('/'); or a "has_parent=/" in your case. But lets say that you were targeting a branch in the structure like "/products/". In that, you would only need $pages->get('/products/')->find('tag_seasons=/tags/seasons/spring'); OR $pages->find("has_parent=/, tag_seasons=/tags/seasons/spring"); You wouldn't need both, as they are synonymous with each other.

Keep in mind that the label "move" is referring to either "page-sort" or "page-move" permission, or both. So just because you see "move" doesn't meant that they can change the page's parent. It just means they can sort within the same parent. They can only change the parent if they have "page-move" permission, and the target location accepts pages of that template (via family settings). So if you are seeing "move" when you don't think you should, test it out. You may find it's actually doing what you want. With regards to why "page-sort" permission refers children of a page rather than a page itself, there's a very good reason. If it didn't behave that way, then you could affect the sort order of pages you didn't have permission to. This is because the sort order of one page affects the sort order of sibling pages. You could feasibly have access to sort some pages and not others, within the same parent. That would be a security problem. So the only secure way for a "sort" permission to be assigned is as a permission of the parent.

Very cool Jeroen. Can you tell us more about how you are using it? Would love to hear more about the use cases and benefits. Maybe it's something that belongs as an option in MarkupCache.

I think what you are doing with this stuff is fine so long as you understand all the security considerations (and it sounds like you do). This is not unlike what Form Builder is doing. But something like files do require even more consideration. For instance, on a front-end file upload, usually I'd want the uploaded files going into a quarantine area (only accessible by passthru script) rather than web accessible directory. That's why I ultimately made a custom Inputfield type for file uploads in Form Builder, rather than using InputfieldFile. So at least for front-end files, I do think it's better not to use InputfieldFile. Though it sounds like your users are still trusted (not anonymous) so it may be okay in your case... only you can decide. It's Monday and I'm having a little trouble waking up, so I don't completely follow yet. Currently we pull the postUrl from the form's action attribute. It sounds like you want it to be hard-coded instead? I don't think we could do that just because it would prevent other admin processes from using the InputfieldFile (though, I don't think any others use it at present). But since this is dynamically set via the form's action attribute, I think it's probably best to set it that way? An alternative is that you could copy that InputfieldFIle.js file out of it's current location, change it how you need it, and have your JS output function use your version rather than PW's.

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.