The WeMeditate project is comprehensive website promoting the practice of meditation through the techniques of Sahaja Yoga meditation. This website is designed to be translated to almost any language world wide and provide the following features:
Knowing the above features will also help one understand broadly what is going on in the code.
We support only the most recent versions of Chrome, Safari, Firefox, Edge, and Opera - including the mobile versions of these browsers. No other browser is officially supported. Internet Explorer is not supported.
brew install postgresql or Postgres.app), for windows you can try the official installer.brew install imagemagick on MacOS)brew install ffmpeg on MacOS).ruby-version). Using a version manager such as rbenv is recommended. Otherwise you may follow instructions on the official Ruby install page.package.json).bundle to install dependenciesyarn to install frontend dependencies.env.development.local (eg. VIMEO_ACCESS_KEY)rails db:setup to create and populate the database.bin/webpack to build frontend packagesrails server to run the server.Once the server is running you should be able to can access these urls
When accessing the admin site you will be asked to login, in the development environment you can use a simple dropdown (shown under the login window) to select which account you want to be logged in as, without having to enter a password.
-webkit-) to your CSS rules. So it is not necessary for you to add these yourself. Sass Documentation.There are a few pointers that it will be helpful to know when navigating the codebase.
This is a core concept of how Rails works. Models represent entries in the database. Views represent pages of the website that will be shown to users. When a user accesses a URL on the website, the controller will fetch models from the database and prepare any other data, then send that information to a view to be rendered.
Concerns are packages of code which get added to a model or controller. This are mainly used for grouping related features that can be reused across multiple models or controllers.
Almost every model in this project can be translated, and most of them can also save a draft version of the model, for a administrator to later approve. This allows the site to have users with multiple levels of access who can propose changes to the site which are then later approved.
However this cross-section of Translaton and Drafting, and also image uploads creates some of the most difficult challenges in the code base, which you will often encounter.
Generally speaking most drafting code is contained to the Draftable concern, and most translation code to the Translatable concern. However these often bleed into other parts of the code.
The website's content is build using independent blocks that can be shuffled, reorganized and tweaked in the CMS. This is done using a visual block-based editor called EditorJS (formerly the CodeX Editor).
This means that much of the CSS and Html is segmented along the lines of these "blocks", unaware of the context in which they are being rendered.
Images and audio are hosted simply on Google Cloud storage and uploaded to via the Carrierwave gem.
However the Video hosting is a little bit more complicated. All our videos are hosted on Vimeo. When the video is hosted on the WeMeditate Vimeo Pro account then we embed it using our custom HTML5 player (using the Afterglow js library), however other vimeo videos must fallback to the Vimeo player.
Those vimeo videos that use the HTML5 player must have vimeo metadata loaded, and must have download links in the metadata (that is why we can only use HTML5 for Vimeo Pro videos)
An additional complication is that some videos, such as those on the Meditation and Treatment pages also have vertical versions of those videos, which are used for mobile. JS/CSS code is set up to switch between these two orientations.
In many parts of the code we render SVGs inline so that we can then manipulate them using CSS. Unfortunately we use two methods to accomplish this inlining. One is the inline_svg gem/method on the server side, which is the preferred method. However some SVGs must be inlined using JavaScript and the js-inline-svg class. This is because those SVGs are hosted externally (on Google Cloud) and the inline_svg_tag method is not able to handle them.
Ideally we would find a solution to remove the js-inline-svg method, and only using inline_svg_tag, but for the moment this is how it works.
The entirety of the CMS rails code is heavily abstracted, because all these models are managed in almost the same patterns. As such, you wll not see the normal rails views folder structures. Instead there is just one index, show, edit, and new view for the whole CMS, and each model is rendered using partials within these views.
Each model corresponds to a table in the database, and collectively these form the core of the website's content. Here is a brief overview of the models used in this site, and how they correspond to site features.
These are used to categorize other types of models
This is mainly useful for those who are not already familiar with Ruby on Rails. This is just a quick overview of the most important folders and files to help you find what you're looking for.
/app - the core files that make this website happenn
/assets - images, fonts, javascript, and css/fonts - custom fonts for the site/images - all images used by the site/javascripts/admin - javascript for the site's admin interface/javascripts/front - javascript for the public-facing website/stylesheets/admin - sass for the site's admin interface/stylesheets/front - sass for the public-facing website/stylesheets/mixins - common sass variables and functions which are shared between the public-site and admin interface./controllers - contains the classes which handle the URL endpoints that are set up in /config/routes.rb/helpers - extra methods that can be used in the "view" files./models - the classes that handle access to the database./concerns - small independent bits of functionality that are shared across multiple models/policies - defines the rules for what actions a logged-in user can take in the site./uploaders - configuration for different kinds of image uploads/views - where we render html/db/migrate - where we define changes to the database/config - overall configurationn of the project
/locales - translation files for every language./routes.rb - defines the URLs that our server accepts/public - contains files that can be accessed simply by adding their path to the end of the website's url./Gemfile - this file defines the Ruby packages which get bundle and installed with the server.The project's servers and hosted and deployed using Heroku. Any changes which are pushed to the master branch will be automatically deployed to the staging server (staging.wemeditate.com). If you need access to the staging server, please ask and a login will be created for you.
Once a change has been verified on the staging server it can be deployed to production in the Heroku dashboard.
If you are implementing a new feature that touches on one of these areas, please use the existing integration or library.
This is a list of some of the key libraries that are used to manage major features.
Ruby Gems:
JavaScript Libraries:
CSS Libraries:
This is a list of all external services used by the WeMeditate project.
This list is provided for reference, to help track down various parts of the site.
G Suite and Namecheap may only be accessed with the sydevelopers.com account, but all other accounts can be set up for people to use their personal accounts.
All accounts are managed and billed by the sydevelopers.com account.