ryan

Like Joss said, you can create your own date field(s) and have them automatically format however you want. This is configured from your date field settings. But 'created' and 'modified' are built-in date fields that have no default formatting options. However, they are still very easy to output in the manner you asked about using PHP's date() function. For instance, if you wanted to output 'created' in the DD.MM.YYYY format, you would do this: echo date('d.m.Y', $page->created);

Out of the box, you can't do this with the comments fieldtype included with ProcessWire. Though you could modify it fairly easily to support what you are asking for. It would just be a matter of adding those 3 additional fields to the schema in FieldtypeComments.module, and updating the other files that accompany it to reflect what you need. Before you do this, it may be a good idea to make copies of all the files you need to modify, and keep it as a separate module in /site/modules/FieldtypeCommentsRating/ or something like that. By doing that, you don't risk overwriting your files during upgrades. Let me know if I can provide more direction in getting you started.

We've got this module just about ready for release. Here's an example of the module up and running and the [largely unstyled] output: http://processwire.com/email-images/

Favicon added to modules.processwire.com

Really happy to see this out and in the modules directory! Thanks for your great work with this module!

Thanks for testing. The behavior you indicated is correct. A user (with a password ) is required to complete the install.

If you are version controlling your entire /site/ dir then you'd definitely want to exclude cache and sessions. My opinion is that if you version control this stuff, just do it on /site/templates/, and let each module be under its own version control (or use Modules Manager). I don't think it's worth versioning /site/assets/files/ for instance, because any change of versions would disconnect it with your database, which is something you wouldn't want.

The WireHttp class is a fairly recent addition to the ProcessWire core, and as you saw it's very minimal at present. I had thought we'd keep adding to it. I like what you've added, and would definitely like to include your additions if that's alright with you? I think the problem here is that very often the .htaccess is not writable, so I don't really like building around something that we may or may not be able to do. I have never personally come across a situation that could be fixed by setting the RewriteBase, though I know others have. What may be a good approach for us is to just have a Troubleshooting section in the readme file, pointing people where to look in the .htaccess file if things aren't working. It does seem like more often than not, the problem isn't the .htaccess file but rather than server not reading it… something that beyond our ability to affect. Still, I like anything that makes it easier for users to install or troubleshoot, but I think this also represents a very small portion of installations. We'll have to keep looking at this though.

There is no performance benefit to count($a) vs. $a->count(). They both end up going through the same route. The reason that you can do count($a) on any WireArray derived types is that they implement PHP/SPL's Countable interface. I kind of like the count($a) syntax because it's consistent with array counting syntax.

It's easier to read. But my opinion is that it's also difficult to understand where it could lead. With GPL you know you are protected from some big corporation coming in and taking over. It keeps others from exploiting ProcessWire's core in ways we can't predict. Profit motives are limited to what you create with or for ProcessWire, rather than what you do to it. ProcessWire's core remains protected. I'm not saying I'm against MIT, and always think that going "more open" is good and worth considering. I'd love to talk to the Concrete5 folks to gain insight on their choice. But we should never be motivated to change the license because someone misunderstands ProcessWire. We should only be motivated by what's ultimately best for the project and users. Currently I think GPL is a great and safe fit for us. Though I also understand the GPL always opens questions wherever you take it. So it's important for project leadership to answer those questions and be clear so that there is no grey area. I think that's what we've done. Though I always invite more questions.

I would setup separate templates for your Parish Council and Cricket Club pages. If they are identical, then avoid repeating code and just have the template file from one include the template file from the other. Setup access control only on these templates. You don't need to setup access control on any other templates that are used for pages further in the structure, as they will inherit from the root parent. Meaning, you don't need to maintain multiple templates for the access control, except for the actual root parent pages (Parish Council and Cricket Club). Even if those two templates have identical needs now (except for access), you'll be better prepared down the road when Parish Council needs something that Cricket Club doesn't, or more.

If you have a robots.txt, I would use it to specify what directories you want to exclude, not include. In a default ProcessWire installation, you do not need to have a robots.txt at all. It doesn't open up anything to crawlers that isn't public. You don't need to exclude your admin URL because the admin templates already have a robots meta tag telling them to go away. In fact, you usually wouldn't want to have your admin URL in a robots file because that would be revealing something about your site that you may not want people to know. The information in robots.txt IS public and accessible to all. So use a robots.txt only if you have specific things you need to exclude for one reason or another. And consider whether your security might benefit more from a robots <meta> tag in those places instead. As for telling crawlers what to include: just use a good link structure. So long as crawlers can traverse it, you are good. A sitemap.xml might help things along too in some cases, but it's not technically necessary. In most cases, I don't think it matters to the big picture. I don't use a sitemap.xml unless a client specifically asks for it. It's never made any difference one way or the other. Though others may have a different experience.

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.