ryan

PW doesn't like you putting your own PHP files in or under /site/ or /wire/, as it's trying to protect those from being executed directly. But put them anywhere else and you should be fine.

Your solution makes sense to me. Assuming this code is running in an environment where output formatting is OFF by default, then you'll have to turn it on, as you are. Usually you want output formatting ON when you are generating markup, and OFF in any other usage. You can also set the default output formatting state for newly loaded pages with $pages->setOutputFormatting(true|false).

Have you tried creating a role that has page-sort permission on the parent template, but not page-edit?

I've done this before and used the method SiNNuT mentioned. Made the navigation with something like this: for($n = ord('A'); $n <= ord('Z'); $n++) { $letter = chr($n); echo "<a href='{$page->url}$letter/'>$letter</a> "; } Then pulled the items matching the letter from the URL segment like this (just like SiNNuT): $letter = strtoupper(substr($input->urlSegment1, 0, 1)); if($letter >= 'A' && $letter <= 'Z') { $items = $page->children("title^=$letter"); echo "<h2>Letter: $letter</h2>"; if(count($items)) echo $items->render(); else echo "<p>No items found</p>"; }

I like PSR-0 because it really does have a point and provides that potential for mix and match of tools as you mentioned. This is one I want to implement. But I don't feel the same about PSR-1&2, at least when it comes to some of the code style aspects. Intentional choices about some of these aspects were already made in ProcessWire. While some of these are subjective, I think the choices already made are far better than those in PSR-1&2. So PSR-1&2 won't ever be on the roadmap for the code I maintain, but PSR-0 will.

It'll work with anything that strtotime() recognizes, and I think 'today' is recognized by strtotime. Yes, you would need the date_end field set. Date calculations use unix timestamps so if date_end is participating in any logic, then it would need to carry the date that the event ends, whether it's the same as date_start or some time later. If you don't want to have to remember to do that when editing an event, it could be automated fairly easily with a simple module (let me know if you want more details).

Btw, not sure if this was clear, but I'm using the terms "tomorrow" and "tomorrow +1 day" literally in the selector. You don't have to substitute a variable for those, as it should recognize those terms (it uses PHP's strtotime to translate internally).

$page->[field-name]->remove($[page-you-want-to-remove]); $page->save(); For example, if you wanted to remove the first page: $p = $page->related_pages->first(); $page->related_pages->remove($p); $page->save();

Btw, I'm not suggesting this is the style everyone should use in their 3rd party modules unless they want to. I understand that there are different preferences in this area. Of course I'm not going to shoot down anyones preferences. So this standard is just for PW core stuff. I do see us pursuing the PSR-0 standard with the way we use namespaces in the near future, and we already have a lot in common with much of PSR-1 and PSR-2. But I don't fully agree with all the standards recommended in PSR-1 & 2. I think PSR-1 & 2 would mainly be worthwhile as a compromise for a leaderless project or a compromise for a project with a lot of leaders that don't agree.

It should be fine to put in a regular array (of non-objects), but I don't think a PageArray will work. Whatever you put in $session is best reduced to a native PHP type, so to stuff a PageArray into $session, I would typecast it to a string: $session->pageArray = (string) $pageArray; And to pull it out in the next request, pass that string to $pages->find(), which will turn it back into a PageArray: $pageArray = $pages->get("id=$session->pageArray");

This selector should accomplish that: $pages->find("template=event, date_end>=tomorrow, date_start<=tomorrow +1 day, sort=-date_start"); For disabled events, I would suggest just using PW's 'unpublished' or 'hidden' status, which will eliminate them from your queries automatically. Though you certainly could add an extra "toggle_disabled" checkbox if you wanted to, and include that in your selector.

PW's coding style is visible in any core file. But it's the same idea whether we're talking about code, graphic design, architecture or really anything someone would create: When it comes to code, that translates mostly to not adding extra unnecessary bytes: Avoid having an opening bracket "{" on its own line. Instead, just use a single space before an opening bracket. Only closing brackets "}" should be on their own line. Avoid use spaces for indentation, just tabs. This is what tabs were made for, not spaces. Use just one tab per indentation, of course. Avoid extra spaces around parenthesis unless you think it's really necessary. For example, it's preferable to use function(a, b) not function ( a, b ) Put a space after a comma, just so the comma doesn't visually melt into one of the adjacent letters. Don't put a closing PHP tag "?>" at the end of a file. Use camelCase for most variable and function names except for when the variable resolves to a database column or ProcessWire 'name', then use lowercase and underscores. Use camelCase for class names except always have the first character be uppercase, i.e 'CamelCase' (there may be a more specific term for this). Put a space before and after the concatenation operator, as it's small and disappears (or becomes a sentence period) too easily. For example use "a . b" and not "a.b". And of course, comment as much as possible. Comments are bytes that are always appreciated for communication. Outside of internal comments within the body of functions/methods, PHPdoc style is the standard we prefer. Honestly the biggest one for me is just the opening bracket thing. I can't follow code that contains opening brackets on their own line. It makes the opens and closes so visually similar that I can't can't easily tell them apart. It could be that my eyes aren't great, but at least for me that coding style creates legibility problems. I have to "fix" code before I can read it. With the style I'm using, when I see a bracket on a line (before I see the nuances of the serifs), at least I know it is always closing something.

Either count($page->comments); or $page->comments->count(); will work. You can also do it from selectors before a page is even loaded: $pages->find("comments.count>0");

The $event just provides you with a way to pass data back and forth between the hooked object and method: $event->arguments is an array of arguments sent to the hooked method. So $event->arguments[0] would be the first argument, $event->arguments[1] the second argument, etc. $event->arguments('name') is another option where you can retrieve the argument by name, i.e. $event->arguments('page'); $event->setArgument($n, $value) or $event->setArgument($name, $value) lets you change the value of an argument. This is useful only for before hooks (though set to execute before the hooked method). $event->arguments = $value; where value is an array lets you set all the arguments to the function at once. $event->return is the value that will be returned from the function you are hooking. This is only useful for 'after' hooks (i.e. hooks that you set to execute after the hooked function, rather than before). You can both retrieve this value and set it, if you want to. $event->object is the instance of the object that the hooked function exists in. So if you hooked Page::render, then $event->object would be an instance of Page. See here for full documentation on hooks. ----------- I'm not sure I've got enough understanding of what you are trying to do with your module to say too much, but it looks to me like your hook there might not actually be necessary. I think you've be better off overriding the savePageField method of FieldtypeTextarea. public function ___savePageField(Page $page, Field $field) { $value = $page->get($field->name); $value = $this->getSpecialText($value); $page->set($field->name, $value); return parent::___savePageField($page, $field); }

You could also use a /home/[user]/.my.cnf file: [client] user=your_db_username pass=your_db_pass From there, you can just type 'mysql' and never have to use a password.

This is not part of FieldtypeComments, this is a 3rd party module (though it's one of my 3rd party modules). I'll make it translatable before it's out of beta. Now these ones are part of the core FieldtypeComments module. Looks like I missed these before -- I will update. Make sure your site is outputting in UTF-8. If your server is overriding to some other character set, you may need to add this meta tag in your <head> in your markup: <meta http-equiv="content-type" content="text/html; charset=utf-8" />

None of PW's sanitization/validation functions have to do with SQL injection, since PW's API doesn't involve SQL queries. Eliminating SQL injection is just a matter of using the DB driver (mysqli) the way the manual says to. Specifically, using prepared statements or escaping strings. Using prepared statements is preferable in general, but my personal preference is escape my own strings.

ProcessWire's API doesn't use SQL queries -- it uses selectors. SQL injection is a non-issue in ProcessWire. ProcessWire does not get involved with database abstraction layers, so if you are executing SQL queries then you are using PHP and MySQL (mysqli). You can always add your own database abstraction layers to do whatever you want. But typical usage of ProcessWire for developing a site does not involve SQL. If you are using SQL for something and you want to stick with the DB driver PW is using (PHP's mysqli) then you eliminate SQL injection by either using prepared statements or escaping your strings before putting them in a query. Use it the way you are supposed to and SQL injection is a non issue. Is it possible your company was asking about the security of the software itself? ProcessWire's own queries are well protected against SQL injection, of course. SQL injection is a problem of bad code. If one uses the database driver in the way it is supposed to be used, then you are never subject to SQL injection. Btw, I don't know about what CakePHP is doing, but the whole idea of trying to protect the user from SQL injection (outside of the DB driver) sounds like a security problem in and of itself. We've seen this with PHP's magic quotes, which was meant to protect the user from SQL injection. Anything that tries to protect you from yourself ultimately encourages bad programming practices by making security a grey area. That fosters an environment where many think they don't have to sanitize and validate input, which becomes an even bigger security problem.

Are you sure you have the latest version? I recall this problem in an earlier version, but thought I fixed it. The FieldtypeComments modules already are translatable? Though the translation phrases are not actually in the module file. They are in: /wire/modules/Fieldtype/FieldtypeComments/CommentForm.php /wire/modules/Fieldtype/FieldtypeComments/CommentList.php Though let me know if you've found some phrases I'm missing and I'll be glad to make them translatable.

Thanks for posting this. The website field isn't in there yet, but it planned for 2.3, so I will try to go ahead and get this into the dev branch here shortly.

Thanks for posting this. I also found this a couple of weeks ago through reddit and have been making my way through it. So far seems like all good advice and lots of good best practices. I also like this big 1-page format that remains easy to navigate. Somehow it makes it all seem more approachable. Maybe ProcessWire should have a document like this.

You are too kind Teppo. I'm no ninja on that front -- I break as much stuff as I create. But I do try and account for that as much as I can... if I've been adding stuff that I know has potential to break things or result in any potential behavior change, I put it in the dev branch. If I'm adding code contributed by others, I'll put that in the dev branch. But if I'm updating stuff that is unlikely to break anything for anyone (especially bug fixes), then I'll put it in the master branch. Once I've been running on the dev branch myself for awhile without issue, then I'll try to get some other people to test it out, and if all is good, it gets merged into the master (along with a minor version number bump). I still consider myself kind of a novice with GitHub, so am slowly learning the right workflow here. But as time goes on, I hope to be using as many best practices here as possible. So far I've not been using the dev branch when it comes to more minor stuff. If I don't have something big going on (i.e. stuff that needs more testing), then I'm not really using the dev branch. But I will try to be more consistent with a consistent workflow that predictably goes from dev to master. This isn't the way it should be, it's just me not being a Git expert yet. I'll use a more consistent workflow here, especially now that I know people are looking at the dev branch.

Probably not ideal for really large sites as it clones the /site/assets/files/ directory in creating the profile (which may double the size of disk space used by your site, temporarily). I could add an option to the profile exporter that justs instructs you which directories to download into your profile, rather than copying them. That would make it more useful for large exports. But the profile exporter was originally meant for doing things like exporting the Blog Profile or migrating a new site, as opposed to functioning as a dedicated backup tool.

Definitely moving forward with files fields as soon as possible. But saving to pages doesn't make it an easier prospect only because saving to pages is an option, not a requirement. Most people don't need to save pages and I don't want that to be something you'd have to do in order to get file fields. So I'm still planning on developing these file fields independently of the ones already included in ProcessWire. Though it's always possible I might modify the ones we've got to change the behavior to a broader context that would be inclusive of Form Builder too.

Another update: Form Builder 0.1.5 (the current version) now supports Auto-Responder emails and customizable email templates for both admin emails and auto-responder emails. -- Edit: WillyC somehow I messed up your message. I think I clicked on edit rather than reply when i was trying to post (I probably shouldn't be a moderator) . Can you post again? (sorry)