Jump to content

What do YOU do before you deploy your site?


neildaemond
 Share

Recommended Posts

Thanks to Processwire, I've gotten the confidence to start charging people for my web development and have recently started a web dev business.

Although I'm not too artistic, the flexibility of PW allows me to accomodate the design of any artist I am working with and the API gives me to power to do the fun backend stuff.

Anyways, before I deploy some sites for production, I wanted to ask the more experienced developers out there what kind of steps they take at the end of a project to make their sites 'production ready'.

For example, do you guys combine all your js and css files? do you change any Processwire configurations?

Hearing any tips from you all would be of great help to me.

Thanks in advance

  • Like 1
Link to comment
Share on other sites

I tend to leave the PW config as-is, unless there are good reasons to change anything or add variables. ( I have a textformatter module that takes its config from config.php, for example.)

SEO is always important , so I always install Pete's XML Sitemap module (http://modules.proce...up-sitemap-xml/) and, if it's a port of an existing site to PW then Antti's Redirect Module (http://modules.proce...cess-redirects/) saves loads of time.

Then it's a matter of checking that all your <title> and meta description are all populated with appropriate info, and I also make sure that the html validates. A few small things add up to a significant advantage.

Don't forget the Google Analytics code and to register your sitemap in Webmaster Tools.

And, if you're in any doubt, a bit of user testing. A handful of users is enough to make a significant difference - http://www.useit.com...x/20000319.html.

  • Like 3
Link to comment
Share on other sites

First of all, don't worry too much, you will normally find all the problems after launching :)

Here are some of the things I try to do before launch :

- Check the page titles and meta descriptions. Install the Google webmaster tools to get more useful advice on how to optimise the site for search engines

https://www.google.c...ebmasters/tools

- Create an xml site map and submit to Google (via Webmaster tools) and Bing (http://www.bing.com/toolbox/webmaster)

- If this is the an update of an existing site, setup redirects for old pages to new pages - you can check what old links are currently indexed by Google and start with the top ones. The redirect plugin is great for managing this (http://modules.proce...cess-redirects/).

- Check and update the 404 error page

- Check that all your forms are working and being delivered to email recipients (not stuck in spam).

- Change the admin url from /processwire/ to something more secure

- Turn off any debug modes

- Disable any test accounts and put an extra secure password on the master account.

- Check what print layout looks like (or make print style sheet)

- Browser testing - this is tough one to summarise - there are some sites that let you take screenshots, but the best way I have found is to have multiple virtual machines with IE7, IE8 and IE9 which can be used for more detailed testing and debugging. Then there is mobile device testing!

- Check for broken links and correct redirects. http://validator.w3.org/checklink

- Performance testing - you might want to check for any big performance issues. ySlow is a nice tool for checking and provides some good tips that might be useful for speeding up the site. Don't be too disheartened by the results, not even the big sites get top marks.

http://developer.yahoo.com/yslow/

- Setup analytics to track usage - Google analytics

- Setup monitoring so you know the site is up and running - I really like pingdom.com - https://www.pingdom.com/

- Backup the site files and database!

Then I like to say a little website launch prayer… "dear internet gods, I know things will go wrong but please let the issues be small and easy to fix. amen."

  • Like 7
Link to comment
Share on other sites

First of all, don't worry too much, you will normally find all the problems after launching :)

haha, yes.. I probably will.. sigh~

But, thanks a million, you guys covered all of my check list and added the following good points to it~ The redirects, user testing, validator, yslow, and pingdom are especially good ones. That xml sitemap module has to be one of my favourites.

and, if it's a port of an existing site to PW then Antti's Redirect Module (http://modules.proce...cess-redirects/) saves loads of time.

Then it's a matter of checking that all your <title> and meta description are all populated with appropriate info, and I also make sure that the html validates. A few small things add up to a significant advantage.

And, if you're in any doubt, a bit of user testing. A handful of users is enough to make a significant difference - http://www.useit.com...x/20000319.html.

Here are some of the things I try to do before launch :

- Check the page titles and meta descriptions. Install the Google webmaster tools to get more useful advice on how to optimise the site for search engines

https://www.google.c...ebmasters/tools

- If this is the an update of an existing site, setup redirects for old pages to new pages - you can check what old links are currently indexed by Google and start with the top ones. The redirect plugin is great for managing this (http://modules.proce...cess-redirects/).

- Check and update the 404 error page

- Check that all your forms are working and being delivered to email recipients (not stuck in spam).

- Check what print layout looks like (or make print style sheet)

- Check for broken links and correct redirects. http://validator.w3.org/checklink

- Performance testing - you might want to check for any big performance issues. ySlow is a nice tool for checking and provides some good tips that might be useful for speeding up the site. Don't be too disheartened by the results, not even the big sites get top marks.

http://developer.yahoo.com/yslow/

- Setup monitoring so you know the site is up and running - I really like pingdom.com - https://www.pingdom.com/

Then I like to say a little website launch prayer… "dear internet gods, I know things will go wrong but please let the issues be small and easy to fix. amen."

Link to comment
Share on other sites

Greetings,

Just wanted to say thanks for this discussion. I'm still new to ProcessWire, and I had a similar question.

The fact that such a discussion can take place here so naturally is one of the many reasons I find ProcessWire so good. What you are all discussing here is what one could call "good general practices" for deploying any site. However, in other CMSs, when you ask such a question, you get the general information then you have to go further and say, "OK, now how do I do this in [name] CMS?" With ProcessWire, what I really like is that the answer is simply the answer, and not "Here's how you need to do it in ProcessWire."

This principle seems to extend all the way through ProcessWire -- from templates to JQuery, and more. It's one of the principles that I find very appealing about the system

Thanks,

Matthew

  • Like 7
Link to comment
Share on other sites

Well said Matthew, the end result of PW website is really up to you, not what the system comes up with.

That being said, I have been thinking a lot about building our own "starting profile" (we kind of have one already, but that is not well build). Something more "out of the box" for our clients. That thinking also has some merits - especially if there are lots of sites and multiple people working (also on different areas, like customer support, developing, sales etc). More feature packed default site is easier to demo and sell, easier to maintain if there is lots of similar sites, easier to provide support (technical and helpdesk), easier to write instructions etc... What I am doing (hopefully this year) is to build site profile where would be the most common needs baked in already. What that would mean in our case (we build websites for Finnish associations) are:

  • News section
  • Events section
  • Contact section
  • Few different "basic-page" layouts
  • Blog (maybe)
  • FAQ-section (maybe)
  • Tiny "intranet" section (maybe)
  • Frontpage highlights
  • Few editor roles
  • Some useful modules already installed (redirects, adminbar, link helpers, admin helpers)
  • Using more robust template approach
  • Responsive by default

I hope that it won't take too long that we start to see more and more community driven "starting profiles" like Ryan's Blog profile. There could be things like General CMS profile (kind of what I am doing - although not sure if it will be general enough to share it) and E-commerce site (kind of what here is coming) etc..

  • Like 5
Link to comment
Share on other sites

The fact that such a discussion can take place here so naturally is one of the many reasons I find ProcessWire so good. What you are all discussing here is what one could call "good general practices" for deploying any site. However, in other CMSs, when you ask such a question, you get the general information then you have to go further and say, "OK, now how do I do this in [name] CMS?" With ProcessWire, what I really like is that the answer is simply the answer, and not "Here's how you need to do it in ProcessWire."

This principle seems to extend all the way through ProcessWire -- from templates to JQuery, and more. It's one of the principles that I find very appealing about the system

The Processwire community is indeed very awesome. I wouldn't be as inclined to ask this kind of question any other place, but I know that here I would get reasonable and helpful suggestions.

Processwire seems to attract these kind of respectful and helpful developers. I guess it's easy to help out when the system isn't driving you mad. I love the fact that the more I learn about web development in general, then better at Processwire I get, and vice versa. They go hand in hand, and that IMO is what makes a great CMS/CMF.

I have been thinking a lot about building our own "starting profile" (we kind of have one already, but that is not well build). Something more "out of the box" for our clients. That thinking also has some merits - especially if there are lots of sites and multiple people working (also on different areas, like customer support, developing, sales etc). More feature packed default site is easier to demo and sell, easier to maintain if there is lots of similar sites, easier to provide support (technical and helpdesk), easier to write instructions etc... What I am doing (hopefully this year) is to build site profile where would be the most common needs baked in already. What that would mean in our case (we build websites for Finnish associations) are:

  • News section
  • Events section
  • Contact section
  • Few different "basic-page" layouts
  • Blog (maybe)
  • FAQ-section (maybe)
  • Tiny "intranet" section (maybe)
  • Frontpage highlights
  • Few editor roles
  • Some useful modules already installed (redirects, adminbar, link helpers, admin helpers)
  • Using more robust template approach
  • Responsive by default

I hope that it won't take too long that we start to see more and more community driven "starting profiles" like Ryan's Blog profile. There could be things like General CMS profile (kind of what I am doing - although not sure if it will be general enough to share it) and E-commerce site (kind of what here is coming) etc..

Even your first starting profile is already helpful to me, saves me the time of ripping all the fields and templates out before I start a fresh project. Profiles with what you listed will be nothing short of amazing.

I've been away from PW a bit, and am pretty excited to give 2.2 a whirl~ especially the user system.

I hope that I can help out more in the future as I am now using it quite heavily in my business. I'm going to do a more in depth study of the php behind it before I start making modules or profiles. As I work through it, I think I may see stuff which could use further documentation. If I do, how could I help out with that?

  • Like 1
Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By MoritzLost
      In this tutorial I want to write about handling special cases and change requests by clients gracefully without introducing code bloat or degrading code quality and maintainability. I'll use a site's navigation menu as an example, as it's relatable and pretty much every site has one. I'll give some examples of real situations and change requests I encountered during projects, and describe multiple approaches to handling them. However, this post is also about the general mindset I find useful for ProcessWire development, which is more about how to handle special cases and still keep your code clean by making the special case a normal one.
      The problem: Special cases everywhere
      Since ProcessWire has a hierarchical page tree by default, as a developer you'll usually write a function or loop that iterates over all children of the homepage and displays a list of titles with links. If the site is a bit more complex, maybe you additionally loop over all grandchildren and display those in drop-down menus as well, or you even use a recursive function to iterate over an arbitrary amount of nested child pages. Something like this:
      function buildRecursiveMenu(Page $root): string { $markup = ['<ul class="navigation">']; foreach ($root->children() as $child) { $link = '<a class="navigation__link" href="' . $child->url() . '">' . $child->title . '</a>'; $children = $child->hasChildren() ? buildRecursiveMenu($child) : ''; $markup[] = "<li class="navigation__item">{$link}{$children}</li>"; } $markup[] = '</ul>'; return implode(PHP_EOL, $markup); } But then the requests for special cases come rolling in. For example, those are some of the requests I've gotten from clients on my projects (by the way, I'm not saying the clients were wrong or unreasonable in any of those cases - it's simply something I needed to handle in a sensible way):
      The homepage has the company's name as it's title, but the menu link in the navigation should just say "Home". The first page in a drop-down menu should be the top-level page containing the drop-down menu. This was requested because the first click on the top-level item opens the sub-navigation instead of navigating to that page (espcially on touch devices, such as iPads, where you don't have a hover state!), so some visitors might not realize it's a page itself. Some top-level pages should be displayed in a drop-down menu of another top-level page, but the position in the page tree can't change because of the template family settings. The menu needs to contain some special links to external URLs. For one especially long drop-down menu, the items should be sorted into categories with subheadings based on a taxonomy field. In general, my solutions to those requests fall into three categories, which I'll try to elaborate on, including their respective benefits and downsides:
      Checking for the special case / condition in the code and changing the output accordingly (usually with hard-coded values). Separating the navigation menu from the page tree completely and building a custom solution. Utilizing the Content Management Framework by adding fields, templates and pages that represent special states or settings. Handling it in the code
      This is the simplest solution, and often the first thing that comes to mind. For example, the first request (listing the homepage as "Home" instead of it's title in the navigation) can be solved by simply checking the template or ID of the current page inside the menu builder function, and changing the output accordingly:
      // ... $title = $child->template->name === 'home' ? 'Home' : $child->title; $link = '<a class="navigation__link" href="' . $child->url() . '">' . $title . '</a>'; // ... This is definitely the fastest solution. However, there are multiple downsides. Most notably, it's harder to maintain, as each of those special cases increases the complexity of the menu builder function, and makes it harder to change. As you add more special conditions, it becomes exponentially harder to keep changing it. This is the breeding ground for bugs. And it's much harder to read, so it takes longer for another developer to pick up where you left (or, as is often cited, for yourself in six months). Also, now we have a hard-coded value inside the template, that only someone with access to and knowledge of the template files can change. If the client want's the link to say "Homepage" instead of "Home" at some point, they won't be able to change it without the developer. Also, each special case that is hidden in the code makes it harder for the client to understand what's going on in terms of template logic - thus increasing your workload in editorial support.
      That said, there are definitely some times where I would go with this approach. Specifically:
      For smaller projects that you know won't need to scale or be maintained long-term. If you are the only developer, and/or only developers will edit the site, with no "non-technical" folk involved. For rapid prototyping ("We'll change it later") Building a custom solution
      My initial assumption was that the main navigation is generated based on the page tree inside ProcessWire. But of course this isn't set in stone. You can just as easily forgo using the page tree hierarchy at all, and instead build a custom menu system. For example, you could add a nested repeater where you can add pages or links on a general settings page, and generate the menu based on that. There are also modules for this approach, such as the Menu Builder by @kongondo. This approach is not the quickest, but gives the most power to the editors of your site. They have full control over which pages to show and where. However, with great power comes great responsibility, as now each change to the menu must be performed manually. For example, when a new page is added, it won't be visible in the menu automatically. This is very likely to create a disconnect between the page tree and the menu (which may be what you want, after all). You may get ghost pages that are not accessible from the homepage at all, or the client may forgot to unpublish pages they don't want to have any more after they've removed them from the menu.
      I would only go with this approach if there are so many special cases that there hardly is a "normal case". However, even then it might not be the best solution. The direct relationship between the page tree, the menu structure and page paths are one of the strongest features of ProcessWire in my opinion. If many pages need to be placed in special locations without much structure in regards to what templates go where, maybe you only need to loosen up the template family settings. I have built one site without any template family restrictions at all - any page of any template can go anywhere. It's definitely a different mindset, but in this case it worked well, because it allowed the client to build custom sections with different page types grouped together.
      It's a trade-off, as it is so often, between flexibility and workload. Weigh those options carefully before you choose this solution!
      Utilizing the CMF
      This is the middle ground between the two options above. Instead of building a completely custom solution, you keep with the basic idea of generating a hierarchical menu based on the page tree, but add fields and templates that allow the editor to adjust how and where individual pages are displayed, or to add custom content to the menu. of course, you will still write some additional code, but instead of having hard-coded values or conditions in the template, you expose those to the client, thereby making the special case one of the normal cases. The resulting code is often more resilient to changing requirements, as it can not one handle that specific case that the client requested, but also every future change request of the same type. The key is to add fields that enable the client to overwrite the default behaviour, while still having sensible defaults that don't require special attention from the editor in most cases. I'll give some more examples for this one, as I think it's usually the best option.
      Example 1: Menu display options
      This is probably the first thing you thought of for the very first change request I mentioned (displaying the homepage with a different title). Instead of hard-coding the title "Home" in the template, you add a field menu_title that will overwrite the normal title, if set. This is definitely cleaner than the hard-coded value, since it allows the client to overwrite the title of any page in the menu.
      I'll only say this much in terms of downsides: Maybe the menu title isn't really what the client wanted - instead, perhaps they feel limited because the title is also displayed as the headline (h1) of the page. In this case, the sensible solution would be an additional headline field that will overwrite the h1, instead of the menu_title field. Which fields are really needed is an important consideration, because you don't want to end up with too many. If each page has fields for the title, a headline, a menu title and an SEO-title, it's much more complicated than it needs to be, and you will have a hard time explaining to the client what each field is used for.
      Another example in this category would be an option to "Hide this page in the menu". This could be accomplished by hiding the page using the inbuilt "hidden" status as well, but if it's hidden it won't show up in other listings as well, so separating the menu display from the hidden status might be a good idea if your site has lots of page listings.
      Example 2: "Menu link" template
      One solution that is quite flexible in allowing for custom links to pages or external URLs is creating a menu-link template that can be placed anywhere in the page tree. This templates can have fields for the menu title, target page and/or external target URL. This way, you can link to another top-level page or an external service inside a drop-down menu, by placing a Menu Link page at the appropriate position. This is also a clean solution, because the navigation menu will still reflect the page tree, making the custom links visible and easily editable by the editors.
      A minor downside is that those templates are non-semantical in the sense that they aren't pages with content of their own. You'll need to make sure not to display them in listings or in other places, as they aren't viewable. It may also require loosening up strict family rules - for example, allowing for Menu Link pages to be placed below the news index page, which normally can only hold news pages.
      Example 3: Drop-down menu override
      This one is a more radical solution to override drop-down menus. You add a repeater field to top-level pages, similar to the one mentioned as a custom solution, where you can add multiple links to internal pages or URLs. If the repeater is empty, the drop-down menu is generated normally, based on the sub-pages in the page tree. But if the repeater contains some links, it completely overrides the drop-down menu. It's similar to the fully custom solution in that as soon as you override a sub-menu for a top-level page, you have to manually manage it in case the page structure changes. But you can make that decision for each top-level page individually, so you can leave some of them as is and only have to worry about the ones that you have overwritten.
      Again, this offers sensible defaults with good customizability. A downside is that the mixed approach may confuse the client, if some changes to the page tree are reflected in the drop-down menu directly, while others don't seem to have any effect (especially if you have multiple editors working on a site).
      Finding the right solution
      So how do you choose between the approaches? It depends on the client, the requirements, and on what special cases you expect and want to handle. Sometimes, a special request can be turned down by explaining how it would complicate editorial workflows or have a negative impact on SEO (for example, if you risk having some pages not accessible from the homepage at all). Also, make sure you understand the actual reason behind a change request, instead of just blindly implementing the suggestion by the client. Often, clients will suggest solutions without telling you what the actual problem is they're trying to solve.
      For example: In one case, I implemented the drop-down override mentioned in example three. However, what the client really wanted was to have the top-level page as the first item in the drop-down menu (see the example requests mentioned above). So they ended up overwriting every single drop-down menu, making the menu harder to maintain. In this case, it would have been better to go with a more specialized solution, such as adding a checkbox option, or even handling it in the code, since it would have been consistent throughout the menu.
      Another example was mentioned above: If the client requests an additional "Menu title" field, maybe what they really need is a "Headline" field. I recommend reading Articulating Design Decisions by Tom Greever; it includes some chapters on listening to the client, finding out the real reason behind a change request, and responding appropriately. It's written from a design perspective, but is applicable to development as well, and since UX becomes more important by the day, the lines between the disciplines are blurred anyway.
      Conclusion
      I realize now this reads more like a podcast (or worse, a rant) than an actual tutorial, but hopefully I got my point across. ProcessWire is at is greatest if you utilize it as a Content Management Framework, creating options and interfaces that allow for customizability while retaining usability for the client / editor. I usually try to hit a sweet spot where the editors have maximum control over the relevant aspects of their site, while requiring minimal work on their part by providing sensible defaults. Above, I listed some examples of requests I've gotten and different solutions I came up with to handle those with custom fields or templates. Though in some cases the requirements call for a custom solution or a quick hack in the template code as well!
      What are some of the special requests you got? How did you solve them? I'd love to get some insights and examples from you. Thanks for reading!
    • By hafa
      Hey guys, I was wondering if you could answer a few questions of mine...
      - Does ProcessWire handle high traffic and large content sites?
      - Is PW a suitable choice for building an image-based site? Something like those inspirational Tumblogs we often see, for example: twotimeselliott.tumblr.com and bybuildshop.tumblr.com. If it is, what would be the best practices for building something like that?
      - Is it possible to create custom post types with PW? Like in tumblr we have text, link, quote, image, video...
      - How do we create "categories" and "tags" with PW pages?
      Any guidance will be appreciated!
    • By alevine
      I'm looking for any advice on best practices for creating placeholders in the tree that contain things like selectors, or even assets that should be accessible by end users, but not necessarily browseable.
        In my tree, I have a "Selectors" placeholder, underwhich I have various categories of Pages used for selector values.  Should I have this marked as hidden and/or unpublished to keep it from appearing in any brute-force url attempts?  I'm pointing directly to the specific selector tree when defining my fields, but I'm not sure what ramifications the upper selector's visiblity will have.
      I guess the underlying question is how are those attributes inherited/passed down to children? I know in my searches I can specify to include hidden pages, but if I start my search underneath will I also need to include that?  Is this behavior explicitly defined, or currently just a "that's the way it is as an artifact of the way things are designed" that may accidently change at some point?
      I think a follow up question to this is, how do I best test my site for vulnerabilities/leaked information that's not locked away?
      Thanks as always!
    • By Luke Solar
      Hello All!
      I would like to ask you how you manage to work in a team on a processwire project. This also applies to the case when you develop on different machines (e.g. laptop on the train and desktop office pc).
      For example: two different developers create 2 templates with various fields, then they push/commit their changes to a repository. both can update and merge the changes. but: to make the fields and templates available in the backend you still would have to add the database entries to the "fields" and "template" tables, right?
      What are solutions and best practices for team development?
      Thank you and keep on wiring!
×
×
  • Create New...