How can I get an updated code. rather changing it manually according to pull requests.
wisamx opened this issue · comments
is there project being maintained in another place.
How can I get an updated code. rather changing it manually according to pull requests.
hello,
as qTranslate-X is not maintained since 2016 and its owner does not reply, we have forked/moved to a new repo. See also: #579
I have migrated all the backlog to this new repo: https://github.com/qtranslate/qtranslate-xt
Hello,
I've just found this plugin https://it.wordpress.org/plugins/wp-multilang/
It seams that is really closer to qtranslate-x
Anyone knew it or has used?
It seams that it also compatible with WooCommerce and such other major plugins.
Thanks.
I tried it but it lacked options i needed so i gave up. I also tried WP Globus, not better imo. Currently i'm using my new repo qTranslate-XT, works like a charm and i have no intention to change.
If people need integration with WooCommerce why don't you try upgrading the WC & qTranslate-X plugin? It's very little code, it shouldn't be a big deal! What's wrong with it right now?
As i wrote somewhere else, if the code is clean, well confined and well tested we could add it natively as an extension in qTranslate-XT.
hello @herrvigg,
of course should be a great thing if someone will also mantains other plugin closed to qtranslate-x but I think there will be very difficult.
Anyway thank for your answer, we shure use in our agency for the future the new plugin you've created.
@floopyzicer I'm agree with you that a slug support is important. With qtranslate-x we use the plugin qtranslate slug. It is still working.
Thanks.
@herrvigg you can try contacting https://github.com/LC43 back in the day he was willing to cooperate in fixing even integrating his plugin with q-translate-x team , hopefully he has the same spirit and might join and help fix things around :)
@valerensi i helped around back in the day but i am utterly busy lately sites became only a hoby
What i've been doing with qTranslate-XT is to revive the existing repo and fix the urgent stuff. I'm afraid i won't have time to implement new features, also because i don't like the existing code very much. It would need a lot of refactoring.
Beyond that i'm getting more and more skeptical the original qTranslate is a good solution. The core idea is to patch the content of a single post (with the [:]/{:} blocks) but it comes with many problems and sincerely i consider it's more a hack than a clean solution.
@valerensi the most famous plugins are actually WPML and Polylang. Did you try those? The first one is not free and the other has a free version, but some features such as sharing slugs or translating taxonomy require a fee. I'm now considering to switch to Polylang, doing some tests.
Hello @herrvigg,
WPML and Polylang duplicate contents and it's also very complicated to used by client that have to create a content for each language.
For this reason I'm following your work. I think that qtranslate-x is one of the better solution for now.
Thanks.
Yes i understand, all plugins have their pros and cons, also depending if you are more of a developer, a publisher or a translator.
With qTranslate you get all the localized versions in a single post. This becomes actually a weakness from a database perspective and performance. But this can make the translation easier on the admin side because you have everything already loaded.
Better, though i didn't develop myself any new feature, one very interesting feature comes with the "Copy from" that i resurrected from the last branch. This can make the translator life much easier and i warmly recommend you to try it! For what i tried it works very well so that should be a really great news for the existing qtranslate-X users.
You just need to git clone the new qTranslate-XT repo. Do you know how to do that? As said, qTranslate-X and qTranslate-XT can live together but you need to activate only one of it at a time. They share all options and i don't think there should be any compatibility issue.
What i have not done, and i'm not really able to, is to test all the integration plugins such as WooCommerce. I have no idea how they are intertwined, for example if a plugin looks for a plugins/qtranslate-x path in hard in the code it could be a problem but it should be very easy to fix for a developer having some basic knowledge.
If some people are interested but you don't want to use git i may freeze the new repo for a pre-release so you would just have a zip file to download. The few things i've done (resurrect last branch, cleanup and fixes) can already justify it.
I mentioned on one of the repos, its literally 10 lines to integrate Github Updater Lite into qtranslate that will be able to update directly from Github releases through wordpress. I did it on my own private repo and works awesome.
https://github.com/FacetWP/github-updater-lite
I have integrated this into several projects, and its extremely easy to do.
Less than 10 lines IIRC
This will allow anyone running this new fork to update directly from github when a new release is built.
I don't believe that the team here currently has access to the wordpress plugins qtranslate listing, this would be a way to bypass and allow auto updating until then.
Sounds interesting, but i didn't read about this before. Please could you explain a bit more what is about? It sounds like stuff to update your plugin from a git repo. Which repo are you mentioning here, is it related to qTranslate-X or qTranslate-XT?
Hi Herrvig
This would probably be for XT.
https://github.com/FacetWP/github-updater-lite
I updated my post with more info.
Its just a super easy (integrated into Wordpress) way to update plugin from its Git Repo.
In the plugin header make sure the git is entered
Make sure the plugin header .php has the correct repo and format listed in it.
GitHub Plugin URI: https://github.com/XXXX/XXXXXX.git
GitHub URI: XXXXX/XXXXXX
Include the file from github-updater-lite into the xt package
include( dirname( FILE ) . '/github-updater.php' );
Customize the how often to check for new versions.
2 ways :
Updates are only checked every 12 hours. To force an update, you'll need to remove options starting with ghu_ from the wp_options table, or adjusted the release interval check instead of going through the trouble of dropping the table options. This could easily be put into gui backend option etc.
The plugin looks for GIT RELEASES ONLY. So when you decide to make a new release, people will see update availiable for the new release.
Many thanks, looks good!
I'll check it out better later, but it's so compact so i could certainly integrate it in qTranslate-XT. It would make sense, since this new repo is not an official plugin yet, and it will probably never be until completely refactored and rebranded.
My thoughts exactly. I have integrated it in several personal repos (git hosted custom functions.php for my sites) and its really a fantastic idea and implementation.
Also, any developer using WooCommerce with qTranslate-X is much welcome to try it out with qT-XT. We would certainly need to upgrade the related original plugin, it could be done similarly with an XT version. I don't think they should merge yet so it's better they continue to live separately but help is needed at least for the integration tests.
Sounds interesting, but i didn't read about this before.
I use a lot the original Andy Fragen's GitHub Updater plugin. I do not see any reason why to use Lite version because the original one in very active development phase and regularly updated (I'm not sure about Lite version but maybe I'm wrong).
It works very effective and you could easily forget the wordpress plugins listing...
Hi Picasso,
The lite is somewhat based off the full. The full requires having itself (Github Updater Plugin) as well as the integration.
The full is overkill for giving users access to updated releases over Wordpress.
https://github.com/FacetWP/github-updater-lite
GitHub Updater (Lite)
Enable automatic updates for your GitHub-hosted WordPress plugins.
This is a variant of Andy Fragen's excellent GitHub Updater plugin. If you need all the bells and whistles (BitBucket, private repositories, etc), please use Andy's plugin!
@abclution to have one more plugin - it's not a big problem... The problem is that the Lite was updated 4 months ago. But in any case, I just expressed my opinion
The Lite Version should be enough, we don't need very advanced features. Imo the original is more something you install on your own for custom installations, it's overkill to integrate it in a single plugin.
However i'm checking the lite version, the core idea is good but it has some flaws:
-
first of all, it checks not only the current plugin it is installed under, but all the active plugins! It doesn't make any sense for a local installation in a given plugin! Why would you go and disturb how the other plugins are updating themselves? It can have many side effects, it think it's bad.
-
second, it doesn't display the update information for the available version correctly. They mix up the
plugin pathandplugin slug, it's very confusing (yet another thing that is poorly defined in wordpress).
I'm trying to come up with a fix for this.
All right, so i tested both the Lite and the Full version of GitHub updater. I took me quite some time and i had problems with both.
-
Full version: i think it's a very nice tool and full of features. But it should be installed separately as a new plugin to handle everything globally, it's not something you want to include in qTranslate. It is supported naturally through the
GitHub Plugin URIheader field so in theory there's nothing more to do. However i had many many issues with file permissions when installing the new repo. It didn't work in local repo (MAMP) or in production, i don't know yet where it comes from (bad permissions in this git repo or my own system configurations) but it's not straight forward so i give up for the moment. Strangely enough there were more file permission issues than with the Lite version. I won't spend more time here, this plugin lives on its own and can be installed/tested by anyone. -
Lite version: not clear yet why it checks all plugins, that's very wrong imo. Apart from this there are some bugs when displaying the plugin info that i fixed in my own version (see issues i raised + fix in my own fork). Then i had an issue when installing the new qT-XT repo due to a symbolic link with the readme file. I just duplicated those, since the
readme.txtis for wordpress and theREADME.mdis for git. It's two different things though the content should be roughly the same. After fixing this i managed to make it work!
Since we don't have a wordpress repo, the Lite version could be a temporary solution but it's not ready yet. I'm very cautious and i won't include something potentially risky for other plugins. So it still need to be adapted and potentially it can even be simplified a lot.
Also to say, thanks to both you. You are both right.
The Full version is potentially better but it has to be installed on its own. As i precised later it is supported through GitHub Plugin URI. One nice thing i forgot to mention, the Full Version handles not only the tags but the releases and it converts the release notes from markdown to HTML so that's pretty nice. But i had some issues to be checked better, and another drawback is that it must be installed through git clone. I didn't find it as an official plugin. Also, it's overkill if just meant to be used for qT-XT. Fine for developers but not for all.
We want something simple so i think the best would be to repackage internally the Lite version after some cleanup.
Mmmm i think i found the reason why GitHub Updater Full is failing, it may come from the few empty folders in dev. This looks like an issue in GHU itself or how they install the new repo after downloading it. Strangely enough it was not a problem for the Lite version! But it would be nice if it works with the GHU Full so i'll do more tests to confirm this.
Also, both of them seem to dislike symbolic links in the git repo but there was only one that i just removed in qT-XT (the readme file).
@herrvigg if you’re having issues with GitHub Updater please create an issue. I’m sure we can figure it out.
FYI, updating is done via core update routines so any permissions issues should be taken care of from core. Also, as you’ve discerned, GitHub Updater is not meant to be included in other plugins.
Not quite sure what you mean by empty folders in dev.
There’s lots of info in the wiki. https://github.com/afragen/github-updater/wiki
FWIW, there’s no issue with using GitHub Updater and having your plugin in the plugin directory. If the branch is master updates will preferentially come from dot org.
I made many tests and finally i found the main problem came from user permissions for the plugins i was testing on my production site. So the conclusion is that GitHub Updater (Full) is really an awesome plugin! It does a lot of smart processing to get all the release info, it's a software a great quality, both in the code and documentation. I think it's the cleanest solution for now so I will strongly recommend to use it from the next release.
@afragen : congrats for your awesome plugin! I understand you extract the WP Changelog from the named section in the readme.txt. Do you extract the last available version from the git tags or also from the github releases? The release is a github entity on top of the git tag and it contains some markup so i was wondering if you had ever considered to parse this?
It's a minor thing but the error message i got was: The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions. I suppose it comes from Wordpress itself and not GHU. Actually the issue was not to copy the destination files but rather removing the directory in use.
What i meant with empty folders in dev were empty directories in partial git path such as here: https://github.com/qtranslate/qtranslate-xt/tree/master/dev. These folders appear in grey on github with the popup: this path skips through empty directories. At a certain moment these folders were displayed in an error message so i thought it was the problem but i was not sure. It seems they have no particular impact.
Another question as you are certainly aware of this: how are the symbolic links handled when the plugin is installed through a tarball? I suppose they can't be recreated as links correctly.
Just as a sidenote for the qTranslate developers: this "dev" folder is not supposed to be released. It appeared after reviving the last branch and i think the original author did manually some cleanup before releasing the official packages to wordpress.org. Actually there is a very nice way to handle that in git through the export-ignore attributes. This allows to exclude some stuff in the tarball archives. I will clean this up for nice releases through GHU :)
@afragen : congrats for your awesome plugin! I understand you extract the WP Changelog from the named section in the readme.txt. Do you extract the last available version from the git tags or also from the github releases? The release is a github entity on top of the git tag and it contains some markup so i was wondering if you had ever considered to parse this?
Thanks. Regarding tags. GHU does parse the tags and uses the most recent ( highest sorted in array_sort ) tag as the download link. GHU can also use GitHub release assets if the plugin requires a build process. More info in the wiki. None of the text in the tag is parsed. But a CHANGES.md or CHANGELOG.md is parsed so you don’t need to include that information in readme.txt.
GitHub does not differentiate a pre_release tag from any other type of tag so be careful.
Another question as you are certainly aware of this: how are the symbolic links handled when the plugin is installed through a tarball? I suppose they can't be recreated as links correctly.
GHU essentially uses the downloadable zip file to install/update in WP core. GitHub does not include submodules ( symlinks ) in their downloads and therefore direct downloads will not contain these elements. There are 2 solutions. Either include the submodules directly in your repo or use a build process and add a built release asset.
There should be no issue with empty directories. Using a .gitattributes file is also a great idea.
BTW, you have a mixed collection of URLs and headers in the new repository that may result in inconsistencies when using GHU. Also, the GitHub Branch tag has been deprecated. 😉
LMK if you have any other questions.
Many thanks for these answers!
But a CHANGES.md or CHANGELOG.md is parsed so you don’t need to include that information in readme.txt.
I would prefer to have a separate CHANGELOG.md file but this is rather a git standard. If you have both a changelog file and a section (readme.txt) which one do you parse? I suppose the file.
But in the Wordpress specs they only care about the readme.txt, containing the changelog section, so i'd prefer not to duplicate that. I already duplicated the readme.txt to README.md (because the symbolic link is not handled well).
BTW, you have a mixed collection of URLs and headers in the new repository that may result in inconsistencies when using GHU.
For the plugin itself there should only be Plugin URI (official URI for wordpress) and GitHub Plugin URI (for GHU) that matter. What other URLs were you referring to?
Also, the GitHub Branch tag has been deprecated.
Good to know, i will remove it!
I only parse a separate changelog file for use in the more details view. If there is a readme.txt file this also is parsed and the information is combined.
For my plugins on dot org I keep a separate changelog and add the recent changes to the readme.txt so dot org sees them.
If there is a separate changelog it takes precedence in GHU, even if there are changes listed in readme.
The mixed collection of URLs refers to the transfer over to the new repository. All of the previous tags have the old GitHub Plugin header as do some of the other branches.
OK got it, many thanks!
For the mixed URLs i hope no one will look for older releases, i transferred them to keep the whole history in case the original repo disappears. The first new release should come soon with the good URI and from this point it should work smoothly. Your GHU plugin should also be very helpful for the non-developers so i'm writing about it in the new installation section :)
It can cause an issue if someone uses GHUs branch switching. Just saying.
Also, dot org likes the readme to be less than 10k or it chokes. Moving older changes to a separate file is a great way to do this.
Then just reference and link the separate changelog at the end of the readme.
I have now considerably updated the new instructions, reorganize changelog and preparing for a new release. Thanks again @afragen your advices were really helpful!
For all. you are welcome to check the new README: https://github.com/qtranslate/qtranslate-xt
Among the big news this will officialize the new "Copy From" feature that was just sleeping in git. Also the fix for the PHP warnings. If some see other important things don't hesitate to write on the new repo.