withassociates / slices Goto Github PK

• Create project rails _3.2.16_ new project
• cd project
• Add gem 'slices' to Gemfile
• Run bundle install
• Run rails g slices:install
  • This command will create app/slices with a .gitkeep
  • Ask if you require a mongoid.yml
  • Creates a Slices initializer
  • Creates application layout without shared/head
  • Creates Procfile so we can run Foreman
  • Say 'all done!'
  • Advise on other commands like rake slices:seed and To create a slice, run...

The omniauth stuff was extracted a while ago.

I'm proposing a defaults handlebars helper. This could be used in slice templates, page main/meta templates and inside composers etc. Perhaps not a perfect solution – defaults should be defined in the model? – but this works at least. Would be especially useful for select fields which might look selected by default, but aren't.

{{defaults title="Hello world" text="Lorem ipsum dolor sit amet"}}

<input type="text" id="slices-{{id}}-title" placeholder="Title…" value="{{title}}">
<textarea id="slices-{{id}}-text" placeholder="Text…">{{text}}</textarea>

Handlebars.registerHelper('defaults', function(options) {
  _.defaults(this, options.hash);
});

rake slices:seed spits out a bunch of horrible looking nonsense

Two things on this:

a) The guides are now incorrect, as MongoHQ is no more - MongoLab has taken its place.
b) The Mongo gem is not of a recent enough version to host on MongoLab's free tier (which uses MongoDB 3.0.7) - we'd need to use >= 2.0 to regain that. On paid tiers, you can choose an older version of MongoDB, but I feel there's worth in having a free option!

Hi guys,

It seems that the text field helper is missing?
https://github.com/withassociates/slices/wiki/Using-The-TextField-Helper

Will this be added?

Many thanks!

Please can you advise on how to link to the next or previous page from your current page?

I can use will_paginate for navigation on the set of pages, but I'd like to navigate to the siblings of individual pages.

Apologies for two (not real) issues in a week; outside of the Wiki I'm making quite slow progress. (Inside the Wiki Slices is a dream!)

Summary

Move the documentation from the wiki to a new directory in the project called doc or guides. Do some spring cleaning in the process.

Motivation

Documentation generated from inline comments is great but there is still value in a set of “guides” organised in a cookbook style. This is the purpose the wiki currently serves. Unfortunately, the wiki has gone untended and has fallen out of sync. In part, this is because the wiki is independent of the codebase and easily ignored. Moving the documentation from the wiki into the repo will help us version the two in lockstep.

Detailed Design

We create a new directory in the project called doc or guides and add in all guides from the wiki that are still relevant/accurate.

With this in place, any PRs that introduce significant new APIs should include relevant patches to the guides.

Drawbacks

This does not change the fact that the guides need attention and maintenance. It does not magically fix the problem of keeping the two in sync, but it will allow people to view the guides as they stood at a particular tag or version.

Alternatives

Leave the wiki in place but pay it more attention.

Unresolved questions

None at this time.

Two levels of user permissions - so someone creates an article/page, and the article/page is held in a holding pen until an admin approves it

here

and possibly other places (need to check).

Select multiple assets in the asset library, and download - maybe a 'Download' button next to the 'Upload' in the top bar?

This is useful for when I don't want to bother Tom about sending me the files already on projects.

Summary

Currently, Entries are forced to use their parent's layout. This can be overridden by defining entry? to false, but this is undocumented and unintuitive.

Motivation

Often, we want to opt-out of Entry templates, as it isn't appropriate for the site in question. We already have the mechanism available to do this, we'd just like to expose this choice to the end user.

Detailed design

To opt-out of Entry templates, define the following in your Set Entry model:

# app/slices/foo_set/foo.rb
class Foo < Page
  def use_parent_layout?
    false
  end
end

When true:

• Disable layout selection on individual entries
• Enable Edit entry template and Placeholder slice capability

When false:

• Enable layout selection on individual entries
• Disable Edit entry template and Placeholder slice capability

Generators

The new generated entry model would like something like this:

# app/slices/foo_set/foo.rb
class Foo < Page
  # Set this to `false` to enable arbitrary layouts on individual entries.
  def use_parent_layout?
    true
  end

  def template
    "foo_set/views/show"
  end

  # Uncomment the as_json method if the page defines fields that are
  # shown in the admin UI. Pass a hash to merge() that contains each
  # field.
  #
  # def as_json(options = {})
  #   super.merge(published: published.to_s)
  # end
end

After running the install guide on a fresh Rails install, I get this while accessing /admin. The home page (/) appears to work fine in that it renders a blank page.

Ruby 2.0.0-p353 & Rails 3.2.16

In the entries controller we could change the raw_entries method to return just the set page entries, rather than all documents of that type:

def raw_entries
  @page.entries(entry_type)
end

That way we could use the same set slice on multiple set pages. What do you think?

It's possible to add children to set pages by rearranging the sitemap, but there is no Add Child button on a set page.

The double rendering of the _form partial here:

<!--[if !IE]> -->
<%= render 'form' %>
<!-- <![endif]-->

<!--[if gte IE 9]>
<%= render 'form' %>
<![endif]-->

<!--[if lt IE 9]>
  <div class="notice">
    <p>Slices CMS is incompatible with your browser. Please <a href="http://abetterbrowser.org/">upgrade your browser</a>.</p>
  </div>
<![endif]-->

Leads to two event handlers being rendered into :js_head:

<script type="text/javascript">
  $(document).ready(function() {
    $(document).bind("keydown", function(e) {
      if(e.keyCode == 187) {
        window.location = "/admin/auth/google_apps";
      }
    });
    $(document).bind("keydown", function(e) {
      if(e.keyCode == 187) {
        window.location = "/admin/auth/google_apps";
      }
    });
  });
</script>

Not sure if this causes problems yet, but could do with refactoring.

This makes issues very difficult to track down. Should we show a useful error page instead?

Right now we don't show any messages when you can't log in, mess up the password reset form, etc.

So it's easy for someone to work around, if they wanted to.

Hi guys, not sure if this is the right place to comment but I've installed the Slices CMS, I thought I would check it out as it looks great at http://slices.withassociates.com. I'm struggling to get custom Slices ie. title_body to show in the Admin area, is there more detailed documentation?
Cheers

I don't think this file is used anymore, can it be removed? https://github.com/withassociates/slices/blob/master/lib/generators/templates/slices.rb

For example, both of these should work:

{{attachmentComposer field="images"}}
{{attachment-composer field="images"}}

Should we update the google_analytics_tracking_code method to use the new style tracking code?

That'd be trendy huh.

Summary

Add a class method to slice class allowing easy fragment caching of the entire view

Motivation

To add this currently means wrapping the entire view in a cache block

For example, consider FooSlice:

# app/slices/foo/foo_slice.rb

class FooSlice < Slice
end

<!-- app/slices/foo/views/show.html.erb -->
<div>
  <p>
    <%= some_expensive_method %>
  </p>
</div>

Adding the cache block would give the resulting code, potentially adding an extra level of indentation to most of the file.

<!-- app/slices/foo/views/show.html.erb -->
<% cache slice do %>
  <div>
    <p>
      <%= some_expensive_method %>
    </p>
  </div>
<% end %>

Rather then having to add a cache block to the view, we would prefer to add a class method/macro to the slice to signify that the entire view should be fragment cached.

# app/slices/foo/foo_slice.rb

class FooSlice < Slice
  fragment_cache_view
end

This method could allow the passing of optional extra cache keys:

fragment_cache_view 'addition-key'

In an attachments Slice, images only appear if I call for the :admin size. Using the following will only render the caption, and no image.

  <ul class="images">
    <%- slice.images.each do |image| -%>
      <li>
        <%= image_if_present image.asset, :original %>
        <div class="caption"><%= markdown image.caption %></div>
      </li>
    <%- end -%>
  </ul>

I've checked the direct paths for admin and original size images, and they both exist (system/files/.../.../original/file.jpg and system/files/.../.../admin/file.jpg).

It will be using admin's system time zone, so if they are inputting times for events in a different time zone it may be confusing. E.g. if they are in France and enter 9am, that will end up being 8am UK time. Being clear about the time zone will help with this.

Depending on the use case in the project using Slices, it might make more sense to ignore the admin's time zone and always interpret the time in some other, fixed time zone. E.g. if the events are always in London, then time can be interpreted in that time zone.

Some Slices sites seem to be displaying 'last logged in: never' even when we know that users have logged in

When attributes[:permalink] is an empty string attributes[:name] should be used to create the path

https://github.com/withassociates/slices/blob/master/lib/slices/tree.rb#L91

https://github.com/withassociates/slices/blob/master/config/routes.rb#L36
Slices that POST to / are not routed correctly.

Summary

Add linting and/or tests that promote the addition of validation to Slice models.

Motivation

Templates that depend upon data which may not be available is a common source of errors in Slices.

For example, consider FooSlice:

# app/slices/foo/foo_slice.rb

class FooSlice < Slice
  field :bar, type: String
end

<!-- app/slices/foo/views/show.html.erb -->

<p><%= bar.upcase %></p>

If bar is nil (which it will be by default) this will raise a NoMethodError and the entire page will fail to render.

Rather than introduce null checking to templates, we would prefer to enforce these dependencies at the slice-model level:

# app/slices/foo/foo_slice.rb

class FooSlice < Slice
  field :bar, type: String
  validates :bar, presence: true
end

This enforces consistency at a lower level and prevents both full blown render failures and incorrect renders.

I think this definition of as_json should be outside of the PageInstanceMethods module:
https://github.com/withassociates/slices/blob/master/lib/slices/has_attachments.rb#L73

Out of the box, Slices does this - just rescues exceptions and outputs a single line to the log with request path and params. The exception name and backtrace etc. are lost. In some apps we override the exception handlers to report to some third party error tracking service (Raygun/Sentry/whatever), but it would be nice if, by default, some more information was put in the log.