Enable emojis & fix migrated blog posts #68
Conversation
Enable emoji support in blog post. This allows us to fix migrated blog post as well as using emojis easily in feature blog posts. Document how to use emojis
IMO we shouldn't use display block for all images inside an article. This breaks plugins (such us jemoji) and doesn't allow the authors to decide how they want to render the images in their blog posts (for example if they want to render three images in a row). As I am not sure why this is set and where this is used and it could be a breakable change, keep the display block for all images by now. Add a TODO comment and fix it only for images with the `emoji` class (the ones generated by the plugin).
|
Be mindful this breaks feeds by embedding unescaped xml in titles if they contain emoji. I wrote a crude hack to limit the impact of this for openSUSE/obs-landing@156519c |
Some things got broken in my blog posts: - Emojis: Fix them using Jemoji plugin - Extra ###: Remove them - Broken links: Fix them by adding the missed `https:` (only rendering was broken) - Deleted embedded video: Add it back Some of these problems may be present in other blog posts as well, but there are too many to check all of them. I have also added the license to the subtitle (it was already at the end of the blog posts) and a header image to all my blog posts.
I am not sure what you mean. I have just tried Akregator and my local version of news with an emoji in a title and it works. It renders the emoji tag and not the image, but nothing breaks. 😕 Also, what about using jekyll-feed? This way you don't need to maintain the feeds generation code. |
Ana06
changed the title
| jemoji (~> 0.12) | ||
|
|
||
| BUNDLED WITH | ||
| 2.1.4 |
There was a problem hiding this comment.
d10c9b5 explicitely removed the BUNDLED WITH (unfortunately without any details in the commit message).
IIRC we had some fun[tm] with it in the past because of different bundler versions in Leap and Tumbleweed (leading to "wrong version" failures), and in the end removed the BUNDLED WITH to avoid the versioned dependency. However, I'm still not familiar with ruby, so please take this with a grain of salt ;-)
There was a problem hiding this comment.
I honestly don't understand why BUNDLED WITH was removed. It specifies the version of Bundler used to create the Gemfile.lock file. When installing the dependencies Bundler fails if your version is older than the version that created the file. This way you ensure everything works. Removing the version is IMO a bad idea, as when I install the project I don't know anymore which version I should use (and the same for production). You are removing the specification of the version dependency, but the dependency still exists and the something could break. I think we should keep BUNDLE WITH (in general we shouldn't modify this file manually) and either:
- Update bundle in production to use a version higher or equal to the one used by the developer (or even better the newest version of bundler)
- Document the desired version of bundle that the developers should use
Updating bundle is not a big deal and I think it is a good idea to use a newer version, so I would go for option one, except if there is a reason not to do it this way (I don't know how the deployment is done).
@hellcp can you please elaborate on what you mean? |
|
Sorry for the late response
I did check it and huh, well, now I wonder if that fix is even relevant anymore in obs-landing, will have to check later, thanks
We did, it's not extensive enough, and doesn't provide everything we need. Granted a lot of our jekyll stuff is just plugin on plugin on plugin so it's no wonder ;) |
|
@cboltz would you create obs project openSUSE:infrastructure:jekyll so we can get newer bundler building so this deploys after merging? |
Done, and added permissions for you. |
|
The machine is ready to take this, so LGTM |
Enable emoji support in blog posts. 💘 😻 💚 This allows us to fix my migrated blog posts (and possibly others) as well as using emojis easily in feature blog posts. To be able to do this I needed to override the
display blockused for all images inside an article as it broke the plugin. IMO we shouldn't use display block for all images inside an article. This, apart from breaking jemoji (and possibly other plugins), doesn't allow the authors to decide how they want to render the images in their blog posts (for example if they want to render three images in a row). As I am not sure why this is set and where this is used and it could be a breakable change, I have kept the display block for all images by now. I have added a TODO comment and fixed it only for images with theemojiclass (the ones from generated by the plugin).I have fixed my migrated blog posts and added the license to the subtitle (it was already at the end of the blog posts) and a cover image.