Website Development 101: Workflow? Checklists? Best Practices?

Hi folks! New to MODX. I'm looking to start building "traditional" websites with MODX that have the capacity to grow and adapt over time to meet client needs.

What do I mean by traditional? A few basic pages (home/about/contact etc), news and updates posts, list of upcoming events, some event pages, that kind of thing.

I'm hoping to learn from those who are already adept at building websites.

• How do you start (after a basic MODX install)?
• Are there packages you typically install to get started?
• How to you bootstrap your CSS and HTML? Any frameworks or reusable templates?
• Best practices for laying out the site?

I know this is a big question, but with all the flexibility MODX provides, I'd love to piggy back on what's been working for people and not design myself into a corner.

Any good forum threads, blog posts, or other resources I should be reading?

Thank you! [ed. note: patzer last edited this post 11 years, 2 months ago.]

Personally for me, I have built up a custom package that I made with PackMan (http://rtfm.modx.com/display/ADDON/PackMan) of commonly used resources, chunks, and packages, which I import from a fresh install. This covers various things such as links to javascript libs, opengraph bits and bobs, basic SEO information e.t.c

The addon's I mainly use (in no particular order) are :

• getResources
• wayFinder
• MIGX
• phpThumbOf
• Googlesitemap
• Ace
• TinyMCE

When making a custom template in MODX. I start with making it ALL in the template. Then, I seperate it out into header/footer chunks (as a basic example). This is a good opportunity to see commonly used code, and remove duplication as you go through.

I personally use skeleton JS instead of any bootstrap theme frame works, mainly because the stuff I do is highly different from one project to another. Skeleton JS just helps with basic content layout and responsiveness.

Hope this helps you in some way.

I don't build an awful lot of traditional sites anymore, but when I do I always start with a static .html page and start integrating it when it's done. Replacing any markup with the dynamically generated markup from snippets like Wayfinder and getResources.

Hi Geoff - welcome to MODX!
Our workflow is very similar to Graeme's. We have a reference MODX site - complete with a set of standard packages and chunks - that we clone for each build. Some of the packages we use in most builds include:

• getResources
• FormIt
• Wayfinder
• SimpleSearch
• Breadcrumbs

and then we add any relevant packages to a specific build (e.g., 'Articles' if we're building a blog site). We try and keep the reference site pretty lean - that way individual sites only have what they need. We also have some 'standard' chunks we've developed and make use of in each site (e.g., a pageCopyright chunk that creates and correctly displays a copyright message).

As for the development workflow, I always start with developing standalone HTML. This includes any CSS framework we mght be using (usually 960gs (http://960.gs/), unsemantic grid (http://unsemantic.com/) or bootstrap (http://twitter.github.com/bootstrap/)). Once the HTML is complete, I transfer each [different] layout into individual templates, then work my way through each of the templates and move repeated content - such as header/footer code - into their own chunks.

Obviously the more sites you build the better the workflow gets (hopefully!). If I could give you one tip to help speed things up, it would be to prototype things like dropdown menus (using Wayfinder) & breadcrumbs and nail down the overall structure and CSS class names within the menu/submenu/menu items. Once you have this you can build the HTML with the same class names, and this will make the whole transition from HTML->MODX templates faster and easier. For instance, Wayfinder examples use first & last CSS class names for menu items, and although you can obviously change these (or not use them), in your early days of MODX dev, it's much easier to keep everything as per tutorials so you can follow along. Knowing the code each package outputs and using it in your HTML can save so much time!

Oh, and obviously everything (especially the HTML) is version controlled! [ed. note: drpuff last edited this post 11 years, 2 months ago.]

This is all *very* helpful, and exactly what I was hoping for. Great practical suggestions. I hope others chime in as well.