Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMS v3 #1027

Open
owen2345 opened this issue Dec 15, 2022 · 8 comments
Open

CMS v3 #1027

owen2345 opened this issue Dec 15, 2022 · 8 comments
Assignees
Labels
Milestone

Comments

@owen2345
Copy link
Owner

Hey guys @texpert @brian-kephart
I was thinking to work on the version 3 of the CMS with the following things:

  • Create from scratch (excluding multisite support)
  • Rails 7 support (probably using hotwire/turbo/stimulus or perhaps reactjs)
  • Use activestorage instead of the current one to manage media files
  • Include the ability to migrate content from the v2 into v3

As always, open to hear other features to be added or removed

Would you like to be part of it?

@owen2345 owen2345 self-assigned this Dec 15, 2022
@texpert
Copy link
Collaborator

texpert commented Dec 15, 2022

Hi, @owen2345!

I'm in, as long as I will have spare time to dedicate.

  • Create from scratch (excluding multisite support)
    • I wonder why create from scratch and not refactoring? Step by step refactoring should be faster to achieve, less disruptive and easier for migrating different content
  • Rails 7 support (probably using hotwire/turbo/stimulus or perhaps reactjs)
    • Oh, no, just not React, please! :) Hotwire is an exciting way to go!
  • Use activestorage instead of the current one to manage media files

@brian-kephart
Copy link
Collaborator

@owen2345 Great to hear from you!

  • I actually use the multi-site feature. I would be sad to see it go.
  • I use Camaleon on Rails 7 right now. It works well.
  • I agree with @texpert, please no react :) I agree about using Hotwire, since it's included by default and because I already use it.
  • I am in favor of Active Storage. I always prefer using the Rails defaults to avoid additional dependencies. I've been meaning for years to write an Active Storage uploader for the current version, but I've never gotten around to it. I think it would be the easiest for both setup and maintenance since it's a part of Rails.
  • An additional feature I would propose is to use the default Rails test stack. This would avoid upgrade issues with Rspec and DatabaseCleaner, as well as reducing test configuration. Most of our tests could be done using Rails system tests. It makes parallelism easier too, which should speed things up.

Overall, I'm in favor of any change that reduces dependencies, or at least uses dependencies that are Rails defaults.

I would like to be a part of this, but I'm not sure how much I'll actually be able to get done based on my current work. Once the work is more defined and broken up into parts I'll have more of an idea.

@brian-kephart
Copy link
Collaborator

Also, we should use ES6 modules for the assets as discussed in #1025. It seems like this approach would have the best support for use with both import maps and bundlers.

@owen2345
Copy link
Owner Author

owen2345 commented Dec 18, 2022

@brian-kephart I thought nobody was using multi-site feature hehe.
Then probably is better @texpert suggestion: refactor the cms step by step.
Some main goals IMO:

  • improve performance (too slow)
  • recreate documentation (I suggest to use github pages to easily keep it updated)
  • Improve admin UI for easier and intuitive usage
  • Improve/add or recreate tests (at that time i was not a fan of tests)
  • improve code quality (the cms includes my first code in ruby, some of them were developed by my students at that time)
  • Reduce dependencies (already in progress, great job so far)

@texpert @brian-kephart What other goals would you like to add or exclude?

As it could be a step by step refactoring, it does not require a fulltime dedication.

@owen2345
Copy link
Owner Author

Also, we should use ES6 modules for the assets as discussed in #1025. It seems like this approach would have the best support for use with both import maps and bundlers.

I agree. Since IMO, the es6 will be the standard in the near future.

@brian-kephart
Copy link
Collaborator

@owen2345 I think your list is pretty good. Most of what I can think of is for making onboarding easier.

We have rails generate camaleon_cms:install for installing in an existing Rails app. I would like to make a shell command for installing a brand new app.

So instead of this...

rails new my_cool_app
cd my_cool_app
bundle add camaleon_cms
rails generate camaleon_cms:install
rails db:migrate

... you could just do this ...

camaleon_cms new my_even_cooler_app

... and it would create a whole new Rails/Camaleon app, ready to run.

Additionally, I think it would be nice if the sample site generated included basic getting-started documentation, or a tutorial. So, when you start the app, it gives you some tips instead of listing features. Basically, helping people learn the basics by clicking around the sample pages instead of switching back and forth to separate documentation.

We should also decide how to publish the new docs. Right now @texpert and I don't have access, so it's hard to help. We could do a GitHub wiki, but it seems wrong not to make a docs site with Camaleon :)

@owen2345
Copy link
Owner Author

I like your idea @brian-kephart

  • Add shell service to generate the entire app (rails + camaleon)
  • Use some getting-started documentation as the default content

About the access, I thought I provided you the credentials, so sorry my bad.
Please send me your email address to add you as administrator in Camalaone CMS @brian-kephart @texpert.
Another small topic could be to improve authentication to use email instead of username

@texpert
Copy link
Collaborator

texpert commented Dec 19, 2022

Hi, @owen2345!

I have just sent you a message by email, so you'll have my email address.

This was referenced Jan 8, 2023
@brian-kephart brian-kephart added this to the Version 3 milestone Feb 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants