Developer Policies

Home Knowledgebase Developer Policies

General

  • Only use Google’s Invisible reCAPTCHA when using a Google CAPTCHA.
  • Do not use a CAPTCHA that is not Google’s Invisible reCAPTCHA without express permission.
  • Website Search & Filter utilities must operate without page reload. It must be customizable by our clients, non-developers. And it must include predictive search capabilities. Functioning identically to WPFacet.com a WordPress Plugin.
  • No images, styles, scripts, etc… should reference or depend on the URL or domain. This way we do not have to update them when switching environments.
  • All websites must have GDPR and Consent alert accept. Use discretion on placement but the default should be bottom-right in a fixed position with dismiss button that saves a cookie so they don’t keep getting asked. Should also

Setup

  • Include a script that will automatically create the database when php artisan migrate is run.
  • Test Migrations so others don’t have to debug them before you commit them to the repository.

Server

  • Even when doing local development, always have the site running with SSL / https. Ensure that HTTP reroutes to HTTPS.
  • Do not delete the .env.example file. Ensure it remains under version control.

Database

  • Ensure that all database tables have a prefix of the client’s project name in acronym form. For example, if the project is theportlandcompany.com then it’s ‘tpc_’
    • Why? Because this improves security, and it aids in debugging because we can see which tables we created the database tables and not another application.
  • You should not create test users that aren’t @theportlandcompany.com If you need test addresses created ask your supervisor.

Styling

  • All sites should be built using Bootstrap unless discussed and put in writing otherwise. This means every single element should use proper bootstrap classes and those BS classes should be extended to use the clients brand colors.
  • All alerts must use proper class. For example, validation errors must use red alert. Must log in alerts should be Warning (Yellow) class. Etc…
  • TRANSITIONS & EFFECTS
    • All sites should have fade in, slide up effect on navigation items. 500 milliseconds between each navigation item.
    • All sites should have a magnify effect on buttons and clickable containers such as Bootstrap Cards. It should not shift or distort any elements. And it should be 15% increase of all elements.
    • All elements with transitions should ease in AND out smoothly. Easing out should be 50% faster than easing in.
    • All hover transitions should be less than 1 second.
  • SLIDESHOWS & IMAGES
    • Slideshow – Must always have legible text. If the PSD lacks this specification the developer is still responsible to ensure text is legible by alternating colors against backdrops that cause the text to be illegible due to similar colors.
    • Images – anywhere on the site – must NEVER have a stretch or squished photo. Photos should, depending on the design demands, have a 100% height OR 100% width – with the opposite height or width being auto. This will cause it to fill the available space without distorting the image. In cases where the photo still doesn’t properly fill the space you may crop the photo.
    • Image Cropping – Users are NEVER responsible to edit photos dimensions apart from uploading an image that is high resolution. The website should crop and center the image accordingly. Even creating multiple versions for the various places it may appear on the website.
    • Image Sizing for Speed – Images should ALWAYS be resizing, via PHP, to their max size for the space they will appear in automatically. For example, if a slideshow on the front page is 1024 width, and the uploaded image is 4000 width, then PHP should make a copy of that image and resize it down to 1024, the front end then should load the 1024 version NOT the 4000 version. This is the modern web standard set by Google and others.
  • NAVIGATION
    • Navigation should always support unlimited levels even if the PSD doesn’t show it.
    • Navigation should always match the ShiftNav style on TPC.com exactly in terms of functionality.

Forms

  • All forms must have pre-submission validation to sterilize the data before it’s submitted into the database. In Laravel this can be done with request()->validate([ ‘name-field-name’ => [‘required’, ‘min:3’, ‘max:25’).
  • All form fields must have min, max and character values set for increased security.
  • All forms must highlight the field that has an error before submission using Vue. Laravel also provides a helper for this.
  • All forms must output a proper danger notice explaining exactly what they need to do. Laravel provides a Helper for this.
  • When there is a date field or a time field, use the Boostrap Date Picker feature.
  • All form fields should be the same height, padding, and margin.
  • All form fields should fill the width unless there is a reason not to.
  • All form fields should be intelligently sided by side, so you don’t have a field that is really really wide when two or three fields could be beside each other.

Deployment

  • The media files should be under version control. And they should be deployed with the site.
  • The database should be synced. We do not currently have a method for doing this but this package may be a good fit: https://packagist.org/packages/waelwalid/laravel-database-sync
  • The database should be versioned and backed up with the website daily.



By:
Categorized in:
This post is related to:

Home Knowledgebase Developer Policies

General

  • Only use Google’s Invisible reCAPTCHA when using a Google CAPTCHA.
  • Do not use a CAPTCHA that is not Google’s Invisible reCAPTCHA without express permission.
  • Website Search & Filter utilities must operate without page reload. It must be customizable by our clients, non-developers. And it must include predictive search capabilities. Functioning identically to WPFacet.com a WordPress Plugin.
  • No images, styles, scripts, etc… should reference or depend on the URL or domain. This way we do not have to update them when switching environments.
  • All websites must have GDPR and Consent alert accept. Use discretion on placement but the default should be bottom-right in a fixed position with dismiss button that saves a cookie so they don’t keep getting asked. Should also

Setup

  • Include a script that will automatically create the database when php artisan migrate is run.
  • Test Migrations so others don’t have to debug them before you commit them to the repository.

Server

  • Even when doing local development, always have the site running with SSL / https. Ensure that HTTP reroutes to HTTPS.
  • Do not delete the .env.example file. Ensure it remains under version control.

Database

  • Ensure that all database tables have a prefix of the client’s project name in acronym form. For example, if the project is theportlandcompany.com then it’s ‘tpc_’
    • Why? Because this improves security, and it aids in debugging because we can see which tables we created the database tables and not another application.
  • You should not create test users that aren’t @theportlandcompany.com If you need test addresses created ask your supervisor.

Styling

  • All sites should be built using Bootstrap unless discussed and put in writing otherwise. This means every single element should use proper bootstrap classes and those BS classes should be extended to use the clients brand colors.
  • All alerts must use proper class. For example, validation errors must use red alert. Must log in alerts should be Warning (Yellow) class. Etc…
  • TRANSITIONS & EFFECTS
    • All sites should have fade in, slide up effect on navigation items. 500 milliseconds between each navigation item.
    • All sites should have a magnify effect on buttons and clickable containers such as Bootstrap Cards. It should not shift or distort any elements. And it should be 15% increase of all elements.
    • All elements with transitions should ease in AND out smoothly. Easing out should be 50% faster than easing in.
    • All hover transitions should be less than 1 second.
  • SLIDESHOWS & IMAGES
    • Slideshow – Must always have legible text. If the PSD lacks this specification the developer is still responsible to ensure text is legible by alternating colors against backdrops that cause the text to be illegible due to similar colors.
    • Images – anywhere on the site – must NEVER have a stretch or squished photo. Photos should, depending on the design demands, have a 100% height OR 100% width – with the opposite height or width being auto. This will cause it to fill the available space without distorting the image. In cases where the photo still doesn’t properly fill the space you may crop the photo.
    • Image Cropping – Users are NEVER responsible to edit photos dimensions apart from uploading an image that is high resolution. The website should crop and center the image accordingly. Even creating multiple versions for the various places it may appear on the website.
    • Image Sizing for Speed – Images should ALWAYS be resizing, via PHP, to their max size for the space they will appear in automatically. For example, if a slideshow on the front page is 1024 width, and the uploaded image is 4000 width, then PHP should make a copy of that image and resize it down to 1024, the front end then should load the 1024 version NOT the 4000 version. This is the modern web standard set by Google and others.
  • NAVIGATION
    • Navigation should always support unlimited levels even if the PSD doesn’t show it.
    • Navigation should always match the ShiftNav style on TPC.com exactly in terms of functionality.

Forms

  • All forms must have pre-submission validation to sterilize the data before it’s submitted into the database. In Laravel this can be done with request()->validate([ ‘name-field-name’ => [‘required’, ‘min:3’, ‘max:25’).
  • All form fields must have min, max and character values set for increased security.
  • All forms must highlight the field that has an error before submission using Vue. Laravel also provides a helper for this.
  • All forms must output a proper danger notice explaining exactly what they need to do. Laravel provides a Helper for this.
  • When there is a date field or a time field, use the Boostrap Date Picker feature.
  • All form fields should be the same height, padding, and margin.
  • All form fields should fill the width unless there is a reason not to.
  • All form fields should be intelligently sided by side, so you don’t have a field that is really really wide when two or three fields could be beside each other.

Deployment

  • The media files should be under version control. And they should be deployed with the site.
  • The database should be synced. We do not currently have a method for doing this but this package may be a good fit: https://packagist.org/packages/waelwalid/laravel-database-sync
  • The database should be versioned and backed up with the website daily.

About

Since 2005 we've been offering digital and content marketing strategy and implementation. Including website development, search engine optimization and marketing, search marketing and more.

Continue Reading »

Contact

Email

[email protected]

Phone

503-567-9561

Follow

  • Logo for The Portland Company with a Coyote