I am using tomichj/invitation for a project I'm doing, it has all the functionality I need, except it uses email. And there is no way to disable this email feature from it's config file.
How do I alter it so I can run the gem without it's email function, can I extend a gem's controller to bypass the email function entirely?
You could extend the gem's controller, yes. Another way to do it which would give you more control would be to fork the gem, alter it to remove the email function, and use your fork instead of the main gem. You'd have to pay attention to bugfixes in the trunk, but that shouldn't be a big issue.
You can easily open a gem by using the gem open <gemname> command.
So in your case, you can use gem open invitation. This will modify the installed gem directly. But be aware that updates will remove these modifications.
BTW if you want to use your preferred editor you can specify the EDITOR env variable.
E.g.: EDITOR=subl gem open invitation
Related
So I know I can install the mailer gem from here:
https://guides.spreecommerce.com/user/configuring_mail_methods.html
But it clearly says that generic action mailer settings are more favourable at the top of the page.
I have installed postmark which is sending emails fine in an extension I built. However Spree does not appear to be sending emails when I create an order for a customer. How can I turn these transactional emails on without the Spree mailer gem, as I want to use postmark on its own.
Also where the hell is the listed email section from the documentation?
https://guides.spreecommerce.com/developer/deployment_tips.html
Thanks for any help!
You can set up emails by adding the gem at https://github.com/spree-contrib/spree_mail_settings
Not sure if the message at the top of the page has been changed since this question was posted but it says to use that gem now.
Add gem 'spree_mail_settings', github: 'spree-contrib/spree_mail_settings' to you gemfile and you will get a new page in the admin settings for setting up your email
An update for those facing this issue in 2021:
It's not recommended to use this gem. Instead, use a standard rails configuration: https://guides.rubyonrails.org/action_mailer_basics.html#action-mailer-configuration
This guide on how to fix extensions for Spree 4+ may also come in handy: https://guides.spreecommerce.org/developer/contributing/upgrading_extensions.html
If anyone is desperately in need of this extension, feel free to submit a pull request!
I recently deployed my app to heroku. It uses Devise, which I had to alter the after_sign_up_path so it would redirect correctly to a set page after someone signs up. This works fine locally, but when I deploy on heroku it installs the original unmodified devise gem.
Does anyone know of a way to modify a gem on heroku, or to make it use the modified gem in my vendor folder?
Thanks.
So, in general, it shouldn't be any different deploying your app on heroku than anywhere else.
One difference is that on heroku you're probably running in 'production' environment settings, and locally in 'development'. You can run in production locally too, if that were the issue.
But I don't think it is. When you say you "altered" Devise, do you mean you actually edited the source code inside the Devise gem source itself?
That's not a good practice. When a new version of Devise comes out, perhaps with security patches, what are you going to do? Re-customize the new version? It's not a great maintenance plan. If you really want to do this you can. The best way might be to create a fork of the Devise gem in a git repo (on github or anywhere else), customize that and commit your customizations to the repo, and then point to your customized version of Devise from your own git repo in your Gemfile with gem 'devise', :git => 'http://some.git.repo.clone.url.org'
But it's a bad idea.
Devise probably already supports your use case with configuration, rather than by editing Devise source code. Most experienced devs would consider that a much preferable way to accomplish what you want.
In this case, it looks like you should be providing an after_signup_path method override in your own local app, not modifying the default implementation in devise source. Google for more info, or consult the URL Finks provides in another answer, or post another question specifically asking how to do what you want to do with devise (it's actually nothing to do with heroku), being as specific as possible about what you want to accomplish.
Assuming you forked Devise to your github account, you can point your Gemfile to it by doing this:
gem "devise", :git => "git://github.com/user/devise.git", :branch => "my-awesome-branch"
By the way, I'd recommend you overwrite some devise methods rather than hack the gem but thats just my 2cents.
This may not answer your question but according to devise wiki, you don't have to alter the gem to get the redirect behavior you like, you just need to override the after_sign_in_path_for method in application controller. https://github.com/plataformatec/devise/wiki/How-To%3A-Redirect-to-a-specific-page-on-successful-sign-in-and-sign-out
Example:
def after_sign_in_path_for(resource)
current_user_path
end
I have a number of view helpers I use on almost every project, a set of useful rake tasks, minor extensions to active record, extensions to some gems (inherited_resources).
I'm wondering, what would be a good way to manage these 'snippets'? I wouldn't want to manage a gem for each snippet, or even a gem for each 'type' of snippet. Would it suffice to bundle this into a personal gem? Maybe add the option to specify which helpers/extensions to include in the project?
I could use a 'template' application which I could bundle with this code, but the problem here is if I update a snippet on one project, I want to be able to rollout that update on all projects with minimal effort (i.e. bundle update).
With your requirements, I would bundle it all in a base-zenph-gem and use it in every one o your projects, as it is the best way to have synchronized code over different projects.
Also, make a good documentation for it, as if anyone inherits one of those projects would love to know what is going on.
Instead of a gem with Rails you can create an engine which contains reusable functionality, then you can specify the use of the engine within your applications.
You can read more about it in the Rails documentation: Rails Engines
I'm developing a Rails app. Cool.
I'm also having to develop a component as a Gem.
Basically, the Rails app use Omniauth to allow authentication from an OAuth2 service provider. However, NO strategy exist for this particular service provider, so I am writing one, and using my app to test it (they kind of need to be tested together). Unfortunately, Omniauth now REQUIRES strategies to be packaged as gems, and put into the Gemfile along with the omniauth gem.
So basically I'm wanting to put /my-new-strategy-gem with the strategy contents, IN my /myrailsapp folder, and then do gem "mystrategy" :as => "/myrailsapp", where inside /my-new-strategy-gem there is an actual gem, with gemfile, readme, etc.
The reason I'm asking here is that I tried this before, and Git would not recognize the /my-new-strategy-gem folder inside my main app folder, since it contains its own .git file and other info.
I've heard of making it a submodule, or ways that use the vender folder, and other things, so I'm wondering which approach works best in this situation.
Edit: The reason I wanted to do it this way, too, is so my coding partner who is helping with both, could clone a repo with both, all at once, and we could repackage the standalone strategy gem later.
You can use the :git attribute to point to the git repository for your gem.
http://gembundler.com/git.html
gem "my_strategy", :git => "git://github.com/rcd/my_strategy.git"
I believe you could also do this locally instead of on github.
I have a set of functionality that I am considering packaging so as to use them in multiple projects, but I can't decide whether to choose a gem or a plugin. What is the difference? Which one should I choose?
Gem is currently acknowledged as the 'best practice' for Rails. (You can also package as a gem and include an install.rb so that your project can be optionally be installed as a plugin - see this Rails dispatch article).
Basically the only reason to go with a plugin is if your users will want to be able to modify the code more often than not, as it stores a copy in vendor/plugins. However, with the advent of bundler it's pretty simple to store your gems per repository as well and modify them.
If you go with gems, you get the advantages of dependencies, versions, and the functionality that rubygems.org offers for searching, alerts and so on.
Definitely make it a gem!