Leaderboard

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.

Using these module(s) it should be easy enough to build those things in templates (so no need to mess with module files). Extending or hooking into these modules is also possible (I am happy to add hooks if needed). And of course, we are here to help.

Thanks a million, Ryan. It's the AND - OR that that I didn't know how to reproduce with the API. As usual, it's concise and intuitive. I can't conceive starting a project without PW now!

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.

+1 to that. Working in anything else these days feel like a chore to me.

I think the main thing is that when you know there's an easier tool to work with it makes everything else a chore. I was a bit surprised about the SEO person's response from your post above, but I guess I shouldn't be and thinking about it I had a very similar conversation with someone earlier this year myself who was worrying about re-training to use PW. It can be a hurdle to adopting a new system when clients think there will be a massive learning curve and it's generally just because that's what they've cmoe to expect. I think the main point to get across is just how straightforward things can be when everything is laid out logically. We have the luxury (and it is a luxury compared to most other systems) of being able to have custom fields for everything, and being able to name your fields and order them how you like means it becomes very intuitive to the point where there isn't actually much training required. I'm the same with MODx now - used it for quite some years and going back to it is hard work sometimes. Most of the clients I have that still use it don't need new features though so it's just a case of occasional updates, but I do try and convert them when I can. With this current site I really shouldn't complain and should simply have done more research, but it's the case with most projects when you're taking something on that's already established that you will eventually run into something unforeseen - if you could afford to spend days checking out every aspect of a job before taking it on it would be okay, but you generally have to hit the ground running and get on with it. It helps to vent your frustrations sometimes It's another one to chalk up to experience, but I still don't want to work with anything other than ProcessWire again

Like this?

I like Marc's idea as then you could have a field called gallery that could be a multiple image inputfield and you're away

A variation of Ryan's subsitution code for videos or embeds would probably do the trick. You could type "gallery" on its own line and your template logic could find & replace that with an actual gallery of your choosing. Or is this some different type of thing I'm not understanding?

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.

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.

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.

Solved! Need this: $page = $event->arguments[0]; in the calcMethod function. I suppose that line makes $page contain all the field data... Not sure I understand the $event thing?

I've used this script, built from stuff I learned here to back up sites in the past. It will only work on Linux hosting though. To use it, create a folder above your public_html folder called "backups". In this create two folders called "site" and "db". It must be above the public_html folder else you will end up backing up your backups and you will soon run out of disk space that way Now you need to open the attached file and change the path near the top to the path to your backups folder. Next, scroll down to line 41 and enter your site's root username and password (or a database users that you have created that can read all relevant databases for your site). That's it really - upload it into public_html and call it via a web browser to test it, but it should backup the entire contents of public_html and all databases, plus as a special bonus your mail folder, which on this type of hosting means that even if the whole server bursts into flames you can just re-create the mailboxes, put that folder back and the mail is back too Since it uses system commands to run the backups it won't work on restricted hosting, but the easiest way is to follow the above instructions and if it creates files in your /home/yoursite/backups/site and /db folders that have a filesize greater than 0kb then it will work on your hosting. Because it uses system commands rather than PHP to back up, it won't mater much what size your site is and is suitable for sites in the gigabyte range (all depends on your hardware of course). The other thing to note is that it keeps 7 days of backups and cleans out anything older. You can change that by altering the $livecutoff variable to something other than 7. This could use some improvement of course, but I use SyncBack Pro to download the backups each day to a local drive, and also periodically back these up to an external drive kept elsewhere (can you tell I've had trouble with hosting and hard drive failures before? ). cronbackup.php

@netcarver: luckily there's this neat new thing called "the Internet": http://www.noupe.com/how-tos/10-ways-to-automatically-manually-backup-mysql-database.html. Periodic MySQL dump is easy to set up and enough for most cases

Seeing as this has now been raised (indirectly) have you seen this? Don't be put off by that first diagram, it's pretty simple at heart. AFAIK, it is one of the classic git branch management models (though certainly not the only one) and provides command line tools to help folk manage the workflows themselves so it's actually quite easy to use. I also find gitg to be a very useful tool for managing git repos (there are others like gitk and tig as well).

Maybe the chat button on the forum could be replaced by the irc channel. See this http://community.invisionpower.com/files/file/4888-irc-chat-32/

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.

Thanks for sharing your experience. I stopped working on WordPress sites some time ago, but I offered to help a friend with his WordPress site recently and was surprised by how little had changed. That's rarely the case, but I did have a big client request WordPress once. They were very amenable to other suggestions though, as the work got rolling. Pretty soon the WordPress site was a thing of the past, and the character of the work changed toward a more flexible, powerful collection of tools and resources. Earlier this year I sat in a meeting with a client, across the table from a social media consultant who looked at me and said at one point, "we are using WordPress for this site, correct?" I was sort of shocked, but she didn't really know of any other software, and was used to using WP for everything. She is a bit frustrated that she has to re-train just to use a client's site, but what can I say...it's not like learning new stuff is some rare thing in our industry. This client would have been lost with WordPress. I'm even frustrated by MODx these days, so I must be turning into a real CMS snob. Just got a client's OK to move a large, fairly prominent MODx site to ProcessWire after I built a newer, smaller site in PW for them. So looking at my work, it'd almost seem that "the right tool" is always ProcessWire. But I think it's mostly that ProcessWire is a flexible tool that is well designed to solve common problems.

he re.u go reno bird

There is no credit cards or paypal payment method yet. But each payment method is just an additional module, so it is pretty simple to implement. This file should help you to get started: https://github.com/apeisa/Shop-for-ProcessWire/blob/master/PaymentExample.module Let me know if you need any help.