Efficient development practices with ProcessWire

[Vineet Sawant]

Hello,

I've been developing sites with ProcessWire for a while now, and all those sites have been performing really well.

It's a good enough proof that PW itself is very efficient & well performing system but I'm not sure how efficient coder I'm.

Just wanted to learn from you guys,

what are the things you do to keep PW's page structure clean, few good practices you follow & how do write smarter code that reduces server load, etc.

For example, I learnt following things from tutorials that I always do for every site:

• Creating a site settings page to store all global static variables in one place such as site logo, site title etc.
• Using globals.inc file for regularly needed variables, functions & information
• Under home, creating ajax/json (locked & hidden) pages for processing forms
• Using tags to group fields & templates
• Prefixing field names with template name for easy identification
• Naming similar or related templates & template files with similar prefixes

Thanks!

[Joss]

I know this may sound very obvious, but with field, templates, template files and so on I try and use nice, easy to understand names, remembering that sometimes you may want to sort alphabetically

Since from the website point of view, it only ever sees page names, I can call the rest what I like - so I might as well chose things I have a fighting chance to remember!

When it comes to actually coding, I don't have any fixed way of laying things out, but I try and remain consistent throughout a project - so I will comment in the same style, or tab in the same way and so forth. This makes debugging much easier. I also sometimes break things down a bit. If I have a lot of functions being kept in an include file, I might break those up into multiple files just while I am working, then stick them back together for production. Again, it is really just helping me find my own way about.

Not that anything I do really gets very complicated!

I am a bit influenced by a PERL magician who helped me put together a very early web 2.0 style community site in the 90s. Almost the entire site was in a single file called index. It was scary to work through, but very efficient!

[Vineet Sawant]

@Joss

Thanks. Just like you said I try to write comments, sometimes I write detailed comments first and code later. These comments help in documenting solutions, bugs, issues or those ideas that flash suddenly.

I wish to learn how high performing sites with tons of features are built, I mean what if I wish to distribute a ProcessWire project in a team of 5 people? How will they be working on it? I suck at management so this kind of thing puzzles me.

If you are given a really big project to work on with team of 5 people, which you're expected to develop on PW, what are the things you'll consider?

How will be the logical distribution of work?

I hope you understand I'm just trying to learn from your PM experience which definitely be higher than me as I'm just a newbie!

p.s: let's suppose you've to make Facebook for a small town.

Edited February 23, 2014 by Vineet Sawant

[Joss]

Okay, first of all, I have not done that with websites - well, I did many, many years ago with a large community site, but that was chaos!

However, I have managed huge event productions and video productions where you have a lot of different talent supplying different technical skills with a lot of overlaps.

I also have a nephew who is a lead developer on several very large games.

The trick I have found is to try and reduce overlaps and to make sure the main development parameters are set in stone BEFORE anyone starts coding, drawing or anything else.

So, everyone should know what it is meant to look like, understand every aspect of the brief (not the client brief, but the one you write as project manager) and know exactly what their responsibilities are right down to what scripts or functions they should be writing.

AS part of that process it is worth having a short lived debate on style and structure, then put that in the brief too. Then, when someone goes sick or drops out, their work can be understood. 

That project brief document is important and is often neglected. The last time I did one was for a community zone for an online game where the community applications would need to talk in detail with the game application. Horrendously complicated!

The final project bible for that was 40,000 words long - but nothing was missed out and in the writing of it, we solved huge amounts of tech problems and knew what it would look like, how it would feel and had even tested out how it would work with players and what they thought.

It just needed to be manufactured - and it would have been if the people behind it had actually coughed some money up!

I am often amazed how many large projects are created on the hoof - but then, going by how many IT projects end up as camels (a horse designed by committee) , it is probably no surprise at all.

Imagine Ford walking onto his first production line and saying, "Okay, guys, we are going to make the first mass-produced private vehicle. No, sorry, I have no idea what it is going to look like or how it will be put together, but I am pretty sure it will be called the Model ... er ... something. Right, turn the production line on!"

[Vineet Sawant]

Joss, this is something very important that you've shared. These are words of experience.

Project documentation is indeed very important. I do write down project details on some documents but in the flow of development, I tend to be lazy and ignore to update it.

But now I understand why having a project documentation important, it's the first step & a key requirement for big team based projects.

 Imagine Ford walking onto his first production line and saying, "Okay, guys, we are going to make the first mass-produced private vehicle. No, sorry, I have no idea what it is going to look like or how it will be put together, but I am pretty sure it will be called the Model ... er ... something. Right, turn the production line on!"

That's a perfect example!

[Vineet Sawant]

Wooh... 4 years later, I'm still using PW, lovely!

 

After recently using PW 3.0, I've leart that reducing the number of fields in the entire project is a good way of making sure the fields are being used effectively and efficiently. It also helps in remembering the fields names easily while writing code. Based on this, my latest coding strategy is to create a field of each type of field and reusing them on various templates. It helps in standardizing the field names as well as makes coding faster & easier.

 

[dragan]

Yep - field/template overrides are great.

re: working in a team

I'm a big fan of JIRA (or similar tools). It's good practise to chunk your project into smaller tasks and sub-tasks. We even use it sometimes to estimate hours for quotes. If used right, everyone in the team sees who is working on what (swimlanes view).