Configuration - PushType Docs

(Aaron Russell) #1

During installation, when you invoke rails g push_type:install an initializer file is generated and saved to config/initializers/push_type.rb. This file can be used to configure various aspects of your PushType installation.

Root nodes

By default all node types can be placed at the root of the content tree. Instead this can be whitelisted by passing an array of node type symbols to the root_nodes option.

# Restrict root nodes to HomePage and Page node types
config.root_nodes = [:home_page, :page]


By default, when visiting the root URL of your PushType site (the homepage), the NodesFrontEndContoller will look for a node with the slug home. This behaviour can be changed by setting a different value for the home_slug option.

# Set the homepage slug
config.home_slug = 'landing_page'

The config setting can be overridden in config/routes.rb by passing the :home option:

mount_push_type home: 'blog'

Unexposed nodes

By default all node types are exposed to the NodesFrontEndController when visiting the permalink. Sections of content can be blacklisted (and effectively hidden) from the front end by passing an array of node type symbols to the unexposed_nodes option.

# Hide node types from the NodesFrontEndController
config.unexposed_nodes = [:testimonial, :author_profile]

It’s also possible to add a node type to the unexposed nodes list by calling Node.unexpose! on the class itself:

class Testimonial < PushType::Node

Unexposed taxonomies

By default all taxonomy terms are exposed to the TaxonomiesFrontEndController when visiting the permalink. Whole taxonomies can be blacklisted from the front end by passing an array of taxonomy type symbols to the unexposed_taxonomies option.

# Hide taxonomies from the NodesFrontEndController
config.unexposed_taxonomies = [:manufacturer, :author]

Hey guess what? We can also add taxonomies to the unexposed taxonomies list by calling Taxonomy.unexpose! on the class itself:

class Manufacturer < PushType::Taxonomy

Media styles allow you to configure a collection of reusable geometry strings to be used by the Asset#media method for resizing images on the fly. The built in WYSIWYG editor makes use of these to allow users to easily scale images to predefined sizes.

# Set predefined geometry strings for resizing image assets
config.media_styles = {
  large:    '1024x1024>',
  medium:   '512x512>',
  small:    '256x256>'
# And use them with Asset#media

Dragonfly datastore

PushType uses Dragonfly for managing uploaded images/assets. By default uploads are stored on the filesystem but it’s simple to switch to any datastore.

# Dragonfly datastore configuration
config.dragonfly_datastore = :file
config.dragonfly_datastore_options = {
  root_path:    Rails.root.join('public/system/dragonfly', Rails.env),
  server_root:  Rails.root.join('public')
# For S3 storage, remember to add to Gemfile:
# gem 'dragonfly-s3_data_store'
config.dragonfly_datastore = :s3
config.dragonfly_datastore_options = {
  bucket_name:        ENV['S3_BUCKET'],
  access_key_id:      ENV['S3_ACCESS_KEY_ID'],
  secret_access_key:  ENV['SECRET_ACCESS_KEY_ID']

This is a companion discussion topic for the original entry at

(Priit Pärna) #2

Hey, anyone happen to use Google Cloud Storage for Dragonfly around here? With that gem

I’m getting stuff uploaded to the Storage, but the assets will be broken in the push_type (wrong filenames and paths). Filenames are the same as uploaded (but Storage filenames are totally different, as they randomize them). Can it be somehow mixed up because I had already some stuff uploaded via :file before (to local filesystem) and now moving to :google (cloud)?

(Aaron Russell) #3

I’ve never tried with the google data store so don’t know I’m afraid. PushType doesn’t do anything different or weird with dragonfly, so I would hope all data stores would just work :tm:

Is the issue here that the paths are wrong all them time (eg every new asset you upload has a wrong path), or are you trying to migrate existing assets from local storage to google cloud and the URLs are different.

If the latter then that’s going to be a problem. Each of the different datastores have different ways of generating the file_uids. I’ve not had to do this before so can’t help much. I did a quick google and found this gist for migrating from local to S3 storage, which might point you in the right direction:

(Priit Pärna) #4

Hey… I’m currently trying to track down the issue, but seems like push_type tries to fetch the asset from dragonfly but fails, even when everything is stored nicely in google cloud, here’s a stack of what happens after image successful upload via admin

SQL (1.1ms)  INSERT INTO "push_type_assets" ("file_uid", "file_name", "file_size", "file_ext", "mime_type", "uploader_id", "created_at", "updated_at") VALUES ($1, $2, $3, $4, $5, $6, $7, $8) RETURNING "id"  [["file_uid", "2017/05/12/15/02/bc31664f-37eb-4acf-80a0-e587ae6b497c"], ["file_name", "almost.jpg"], ["file_size", 126717], ["file_ext", "jpg"], ["mime_type", "image/jpeg"], ["uploader_id", "5965cb9f-6c49-478e-8856-fb7f2f707162"], ["created_at", 2017-05-12 14:02:32 UTC], ["updated_at", 2017-05-12 14:02:32 UTC]]
   (12.2ms)  COMMIT
Completed 201 Created in 1671ms (Views: 0.3ms | ActiveRecord: 16.9ms)

Started GET "/media/2017/05/12/15/02/bc31664f-37eb-4acf-80a0-e587ae6b497c?style=push_type_thumb" for at 2017-05-12 15:02:32 +0100
  PushType::Asset Load (1.1ms)  SELECT  "push_type_assets".* FROM "push_type_assets" WHERE "push_type_assets"."file_uid" = $1 ORDER BY "push_type_assets"."created_at" DESC LIMIT $2  [["file_uid", "2017/05/12/15/02/bc31664f-37eb-4acf-80a0-e587ae6b497c."], ["LIMIT", 1]]
ActiveRecord::RecordNotFound (Couldn't find PushType::Asset):

(Aaron Russell) #5

No I can see what’s happening… the google cloud datastore seems to be saving files in a weird way. Can you confirm how the file (and full paths) look in google cloud - does it have the filename at the end of the path or just the uid? eg:

  ... or ...

If it’s being saved without the corresponding filename, then the dragonfly middleware that looks up the file will fail. Refer to the following code:

Do you notice how params[:format] gets appended on to params[:file_uid]? If the file uids don’t have a full filename at the end then there will be no “format” parameter in the request, resulting in a database query that looks by the following file_uid:

2017/05/12/15/02/bc31664f-37eb-4acf-80a0-e587ae6b497c.nil <- .nil is causing the problem here.

Probably fixed by changing the line in code above to:

file_name = [ params[:file_uid], params[:format] ].compact.join('.')

(Priit Pärna) #6

Yes seems that you got it - Google Cloud saves without filename just the uid in the end.

Anything on my side so I can write a work-around for it?

(Aaron Russell) #7

Try redefining the media route directly in the app’s config/routes.rb file. Make sure the following is placed before the mount_push_type line so it comes first in order of preference:

# config/routes.rb
get 'media/*file_uid' => { |params, app|
  file_name = [ params[:file_uid], params[:format] ].compact.join('.')
  asset = PushType::Asset.find_by_file_uid! file_name params[:style]
}, as: 'media'

Let me know if that works and if it does I’ll add an issue to make that change in PushType.

(Priit Pärna) #8
/2.4.0/lib/ruby/gems/2.4.0/gems/actionpack-5.0.2/lib/action_dispatch/routing/route_set.rb:507:in `add_route': Invalid route name, already in use: 'media'  (ArgumentError)
You may have defined two routes with the same name using the `:as` option, or you may be overriding a route already defined by a resource with the same naming. For the latter, you can restrict the routes created with `resources` as explained here:

And your code-block is before mount_push_type

(Aaron Russell) #9

Dang. How urgent is this? If you’re prepared to wait I’ll make sure the fix I’ve suggested goes in to the next version of PushType.

If you’re itching to move on, then you’ll need to monkey patch this class in your own application, making the change to line 15 as I’ve done above:

As an aside, I think the dragonfly google cloud gem is doing it wrong. The uploaded assets should be saved with the correct filename in the first place. I notice the gem is pretty new - might be worth adding an issue to their tracker asking them to generate the file_uid with the filename at the end (as the S3 datastore does).

(Priit Pärna) #10

Thanks alot for pointing things out Aaron! Instead of monkeypatching push_type I contributed to ‘dragonfly-google_data_store’ gem and fixed it inside of that to work like S3 gem. Everything works now with my local built gem, hopefully my pullrequest gets merged and released soon (

Thanks again for digging into it Aaron ;)

(Aaron Russell) #11

Cool. Glad you got it sorted :thumbsup: