search

kurtsson / jekyll-multiple-languages-plugin

I18n support for Jekyll and Octopress
MIT License
923 stars 201 forks source link

Bug fix for page_url #126

Closed perlun closed 4 years ago

perlun commented 6 years ago

https://github.com/jekyll/jekyll/pull/7117 describes an issue I noted with the jekyll-multiple-languages-plugin w/ regards to the page_url tag. It generated deprecation warnings.

That PR was rejected because the Jekyll maintainers felt it was the wrong way to change Jekyll core functionality because of details in how this plugin works. So, here I my suggested workaround for now. Because the regex is set up in the constructor, I had to include the whole constructor code from Jekyll::Tags::PostComparer inline here and just change the parts we want to override. Not very pretty but I don't see any obvious, easier way to get it sorted out for now.

perlun commented 5 years ago

The build failure seems unrelated. @Anthony-Gaudino, would you be fine with merging this?

kleuter commented 5 years ago

@kurtsson could you please review this pull request and others as well?

kurtsson commented 5 years ago

Hi @perlun. The main administrator @Anthony-Gaudino, has disappeared so we are in a bit of a sad state here. I still have access to the Ruby Gem and can release new versions but I do not use any Jekyll sites and have no way of verifying PRs. In short this project really need a new owner, is that you? Or can you atleast verify all PRs so I can merge and make a release?

perlun commented 5 years ago

@kurtsson Hej på dig! 😄 I am not sure I could step in as the owner at the moment because of lack of time & family circumstances, but I am willing to spend a few minutes here and there (I have three Jekyll sites personally, one of which is using this plugin.)

It seems like a good step to fix first would be to get working CI setup. We seem to have been using AppVeyor but I feel it would make much more sense to switch over to one of the Linux-based options (Travis or SemaphoreCI are two good options, I have more experience with Travis so I would probably opt for that.)

The Rakefile has a "build" target so we could start with that - just making sure that each PR builds the example site successfully is clearly better than "no CI" which is what we have a the moment (since our AppVeyor setup is broken.)

If you like, feel free to set up a Travis integration - it might be that it would even build without us even having to provide a single line in our .travis.yml, if we are lucky.