Cloudinary Rails 上 cl_image_tag 的问题

problem with cl_image_tag on Rails with Cloudinary

我遇到了一个奇怪的情况。这就是我最终在 Whosebug 上发帖的原因...

基本上,我在 Rails 6.1 应用程序上有一个 Ruby,在生产中 运行,我最近在其上实施了 Cloudinary(取代 Amazon S3)。 Cloudinary 允许获得具有自定义大小和格式的优化图片,因此使用起来非常神奇。

但是 cl_image_tag 有问题。

当运行我的代码在本地环境中:

将其放入 development.rb :

  config.active_storage.service = :local

导致本标签无法获取图片。因为它错过了存储图像的主文件夹 (my_app/)

<%= cl_image_tag("homepage/banner.webp", quality: 'auto', width: 1932, height: 904) %>

所以如果我想让它工作,我必须写这个:

<%= cl_image_tag("my_app/homepage/banner.webp", quality: 'auto', width: 1932, height: 904) %>

但是如果我这样做,那么我的生产环境将会失败,因为它使用了:

development.rb :

  config.active_storage.service = :cloudinary

index.html.erb :

<%= cl_image_tag("homepage/banner.webp", quality: 'auto', width: 1932, height: 904) %>

.env :

MEDIA_FOLDER_NAME_IN_CLOUDINARY=my_app

所以我发现自己陷入了一种只能在本地工作的配置和一种只能在生产中工作的配置之间。有没有搞错 ?!我错过了什么?我在 Whosebug 或 Cloudinary 的文档中找不到任何内容。

编辑: 我的第一个猜测是 MEDIA_FOLDER_NAME_IN_CLOUDINARYenv 变量仅在出现此行时才加载到代码中:

  config.active_storage.service = :cloudinary

但我不能在我的本地环境中使用它,因为我不想上传我的本地图像并在我的云存储中使用 space。所以我必须找到解决方法...

在此先感谢大家的帮助

你也可以在开发中使用 cloudinary,基本上与生产中的设置相同,这样它就会从 cloudinary 而不是你的本地机器上抓取图像。

# config/environments/development.rb
config.active_storage.service = :cloudinary

好的,我找到了解决此问题的“解决方法”,即使我确定这不是理想的解决方案并且我不应该遇到这个问题。因此,在有人为我提供更好的解决方案之前,这是我的:

application_helper.rb :

Rails.env == 'production' ? '' : "#{ENV['MEDIA_FOLDER_NAME_IN_CLOUDINARY']}/"

application_helper.html.erb :

<%= cl_image_tag("#{cloudinary_folder}homepage/banner.webp", quality: 'auto', width: 1932, height: 904) %>

使用这个助手可以让我在生产环境中将 cloudinary_folder 设置为 "",在开发环境中将其设置为 "my_app/"。

注意:如果您认为我可以只使用 ENV variable.M.. 不,我不能。因为在生产中,Cloudinary的cl_image_tag使用相同的ENV变量来设置需要存放上传图片的文件夹,并获取静态图片。

Cloudinary SDK 设计用于从您的 Cloudinary 帐户而非本地环境交付资产,因此 cl_image_tag 辅助方法未配置为在生成时检查本地应用程序的完整路径URL 但只是根据作为第一个参数提供的路径字符串和可选的转换参数创建它。

Cloudinary 可以选择在 Advanced 计划和更高计划时在同一个父帐户下创建 sub-accounts,因此您可以为开发环境使用一个云,为生产环境使用一个云。每个都有自己的 API 凭据,您可以根据其运行的环境将其添加为环境变量。

如果您使用的套餐低于高级套餐,您可以使用两个不同的电子邮件地址创建两个单独的帐户,这样一个将用于开发,另一个用于生产(这两个不会共享相同的配额。每个人都有自己的配额)。 Code-wise,看起来就像将两个云放在同一个父帐户下一样。您仍然会为每个云提供不同的 API 凭据。唯一的区别是当您登录您的帐户时,您将无法在不同的帐户之间无缝切换 sub-accounts 但您需要在需要时注销并登录另一个帐户。

如果您更愿意采用此路径,也可以继续使用建议的解决方法。这非常好,因为它不需要您分叉存储库并将其与将来的更新分离。