brightin / brightcontent Goto Github PK

due to unescaped ruby in js

see https://github.com/rachid/brightcontent/commit/6ca851a89e06e937612bc3d771931d4a0a22319c

Bij Batavia Stad, waren er aanbiedingen verdwenen die om (22.00) waren toegevoegd. Nadat we hard ".in_time_zone("Amsterdam").to_date" hadden toegevoegd werden ze weer zichtbaar.

Kortom betere datetime management in BC!

Other content item's have give problems in menu's, dirty hacks are needed to make it work. (e.g. setting @page for news_item show, to news_item index)

• Migrations are just copied, but should get a correct timestamp. Maybe generate migrations is better.
• Custom.css can overwrite a customized file

When using the rails-4-2 branch, I get this error:

bundler/gems/brightcontent-b4f73a5772e4/core/lib/brightcontent/core.rb:9:in `require': cannot load such file -- inherited_resources (LoadError)

adding gem 'inherited_resources' fixes this, so this dependancy should be added

User model of BrightContent can conflict with the users of the frontend site. Therefore we could rename our BrightContent user to Admin::User.

I believe this could be very useful functionality for existing users and for generating random passwords for new users that they can then reset themselves.

Hi. I came across this gem and tried to use it in my existing app. But I failed to run it.
So, I added the gem, ran bundle, ran all generators mentioned in the docs, ran rake db:migrate.
After that I tried to run the app and access the cms url.

I got this:

Sprockets::FileNotFound at /login
couldn't find file 'bootstrap'
  (in /Users/ivan/.rvm/gems/ruby-2.1.2@souznedro/gems/brightcontent-core-2.1.0/app/assets/stylesheets/brightcontent/brightcontent.css.erb:2)

I thought maybe you already fixed it in the master. I changed my Gemfile to point to the github, ran bundle and got this:

Bundler could not find compatible versions for gem "responders":
  In Gemfile:
    brightcontent (>= 0) ruby depends on
      brightcontent-core (= 2.1.4) ruby depends on
        inherited_resources (~> 1.4.1) ruby depends on
          responders (~> 1.0.0.rc) ruby

    devise (>= 0) ruby depends on
      responders (1.1.1)

So I no longer wish to spend time on this and roll back all the migration (which was not really easy too as few of them are ActiveRecord::IrreversibleMigration)

Just wanted to let you know that users might have troubles installing your gem and it needs polishing.

See Nikon.

It would be nice if we had a default rendering of boolean (list)fields that is a graphic (red X, green V) instead of 'true/false'.

The gem is deprecated: https://github.com/josevalim/inherited_resources#deprecation-notice. (I also find the extra levels of indirection pretty annoying, eg. if you want to find the implementation of the default actions.)

It should be easy to implement the basic actions generically ourselves (similar to the old DefaultAction module but perhaps a bit cleaner.) I think perhaps we should give up the support for nesting though, and it's something that you can (should?) setup easily per project.

Any thoughts?

De h1 in de header moet specifieker worden gedeclareerd in de css.

See Nikon

Menu rendering makes a lot of queries to load children etc.

I only get the first 30 items in my csv if I don't create a custom collection only for a csv format request. There is room for improvements of the defaults there.

I wanted to use just the crud controllers and views in a project and was able to accomplice this without too much trouble.

But it would be nice if you could do this:

• add a gem (brightscaffold? 😉 )
• inherit controller from gem supplied controller ThingsController < Brightscaffold::BaseController
• add some routes resources :things
• have a nice crud interface for a resource

Then you'd just supply your own layout and take care of your own authorization.

Thoughts?

Page.all.detect{|p| p.url == path} generates a lot of queries on every request (though most cached.)

same action as in the list page (maybe in new window)

Other content item's have give problems in menu's, dirty hacks are needed to make it work. (e.g. setting @page for news_item show, to news_item index)

simple_form is currently preventing Rails 5 from being supported: heartcombo/simple_form#1395

By getting rid the dependency, and using regular form fields or some simple helpers of our own, we could support Rails 5.

(It would also be nice to get rid of the global simple_form config that affects projects that use Brightcontent, should they also use simple_form: initializers/simple_form.rb and initializers/simple_form_bootstrap.rb.)

Dont work, you need to reset the parent to be able to select position.

A lot of elements are used throughout multiple projects, maybe we can make default solutions.

If you give an element a classname, it will be styled the correct way every single time. (you can always tweak it a little to make it fit your needs)

Zie Nudge.

Currently only attribute-, and belongs-to association names are accepted by FilterField. Here an exception is raised if a name does not comply with this rule.

I assume this rule was enforced to ensure a sensible list of filter options could be constructed.

With the introduction of filter field options in 4519e1f this argument does not hold up any longer. We could now default to a string type filter for unknown fields. This would allow for a lot more flexibility as more Ransack power can be harnessed. Some examples:

class BlogsController < Brightcontent::BaseController

  # Filter by multiple attributes:
  filter_fields :name_or_description

  # Filter by has_many relations:
  filter_fields categories_id: { as: :select, collection: ->{ Category.all } }

  # Or both:
  filter_fields :name_or_categories_name

  private

  def end_of_association_chain
    super.includes(:categories)
  end
end

I'd be happy to make this happen. Just wanted to check with you if my assumption is right, or if maybe there are more reasons for restricting filter fields to attributes and belongs-to relations...

In #57 (comment) it came up that we should probably reset the session after logout and after login.

https://www.owasp.org/index.php/Broken_Authentication_and_Session_Management
https://github.com/OWASP/owasp-mstg/blob/master/Document/0x04e-Testing-Authentication-and-Session-Management.md#session-management-best-practices
https://github.com/OWASP/owasp-mstg/blob/master/Document/0x04e-Testing-Authentication-and-Session-Management.md#user-logout-and-session-timeouts
https://wblinks.com/notes/secure-session-management-tips/

I would come to the conclusion that both are desirable.

Problem:
Adding a file to a page doesn't attach correctly when a validation error is raised.

Steps:

1. Edit an excisting page
2. Add a file
3. Edit something so it creates an validation error
4. Save
5. Correct te validation error
6. Save again
7. Edit the same page again

Reproducible: 100%

Creating a page with an empty pages table will not work.

When you seed the tabel everything works fine.

Perhaps because the code assumes a root page.

The will_paginate-bootstrap gem is no longer maintained and the readme mentions no PRs are accepted anymore. However, it causes a Fixnum deprecation warning when a paginated index page is loaded.

~/.gem/ruby/2.4.1/gems/will_paginate-bootstrap-1.0.1/lib/bootstrap_pagination/bootstrap_renderer.rb:11: warning: constant ::Fixnum is deprecated

This PR solves the issue, but as mentioned before, the maintainer no longer accepts PRs.

Don't use 'Model#to_param' in BrightContent, so that you can use this method however you like in the site.

When updating gems, I get a warning:

Ruby Sass is deprecated and will be unmaintained as of 26 March 2019.

• If you use Sass as a command-line tool, we recommend using Dart Sass, the new
  primary implementation: https://sass-lang.com/install

• If you use Sass as a plug-in for a Ruby web framework, we recommend using the
  sassc gem: https://github.com/sass/sassc-ruby#readme

• For more details, please refer to the Sass blog:
  http://sass.logdown.com/posts/7081811

See also rails/sass-rails#420.

Brightcontent depends on sass-rails, which will be deprecated very soon. Let's move to sassc-rails instead.