You probably wondered what happenned to the Extended Profile plugin... Why old SVN URLs do not work? What are those directories v0 and v1 where are sources?.. Why new version requires other plugins?..
Short answer - the Extended Profile plugin has been !..
Long answer - it’s now a completely new plugin! No, it’s not even a plugin!.. It’s now a customization built on top of a new plugin which has similar name - that is over the Extended Fields plugin!
I’m not kidding! The Extended Fields plugin allows you (if you are familiar with ERuby and HTML) to customize versions, issues, projects and so on... Would you call such customizations plugins? The Extended Version, the Extended Issue and the Extended Project?.. Anyway the Extended Fields plugin is out of scope of this news... Check the corresponding announcement for it to learn more! Here let’s discuss what changed!
As far as things has changed much I provide the fix for version 0.0.x (version 0.0.3) so you could keep on 0.0.x... But still I highly recommend upgrading to version 1.0.0! I will also try to fix new bugs in 0.0.x. But new features won’t appear in it! This version should now be treated as an obsolete.
Once switched to 1.0.0 you most likely customize it so it won’t be Extended Profile plugin anymore!.. But that’s the feature! This, of course, will make to support this plugin more complicated. So it can be the last version. But I’m not sure yet!.. If it will be possible I will continue to extend it! If not you will probably find it ok as this plugin is not actually a plugin anymore! But as I said above - it’s now a customization!
So what changed? Nothing at the first glance!.. If you dig deeper you will find that profile fields are actually custom fields! And you can do with them the same what can be done with just custom fields. That is rename, delete etc. That’s actually the main change! The rest did not change much...
A fix of OpenID authentication in Redmine and ChiliProject was earlier available as a feature of the Extended Profile plugin. Now when the Extended Profile plugin has been divided into two plugins (the Extended Fields and the Extended Profile) the fix has been moved to the separate plugin!
The idea to write the Extended Fields plugin came to me when I was analyzing issues with the Extended Profile plugin (that’s why the name is so similar).
The Extended Profile plugin adds many new fields to user profile. Actually the same can be done using just custom fields but unlike custom fields the extended profile fields support “richer” content - links, social usernames which are made links to the social networks when displayed, projects displayed as links etc. Core custom fields cannot be used this way! So that’s why I wrote the Extended Profile plugin... But later I faced many issues related to the approach I chose. Some users wanted more fields, other users wanted less fields... Some functions conflicted with other plugins... I personally wanted more flexibility!..
When disputing with Daniel Seifert (see #1876) I came to the conclusion that the whole approach was wrong! Instead of adding new fields to user profile I should extend custom fields - to add support for new types, to give more control over displaying etc. Other things which were missing and hard to implement in the Extended Profile plugin were already implemented for custom fields e.g. visibility control, position etc.
So this was the story!.. Now meet the plugin! The Extended Fields plugin has the following features:
- Adds new custom field types:
- Wiki text (can contain Textile code which is converted to HTML when displayed);
- Link (hypertext link);
- Project (shown as a project link).
- Adds new properties to custom fields:
- Hint (adds specified text below the form element);
- On registration flag for user custom fields (specifies whether the custom field should be asked on registration).
- Adds the possibility to customize how custom fields are rendered by specifying template files for custom fields and custom field formats;
- Improved the custom field form by changing the text field for the “Default value” of the “Text” type to the text area.
For more details on features check this Wiki page...
SCM Creator (+Github): SCM Creator is going Bazaar (1 comment)
From release to release the SCM creator becomes more powerful! Now it’s not only my personal plugin which was just shared... It has been extended mostly by community requests and patches. This release is not an exclusion - new breaking features were suggested or supported by Mario Luzeiro, Blaž Podržaj and Jonas Götze (thanks, guys!).
Traditionally new major version is released with the support of new SCM - this time Bazaar. Adding Bazaar support (and help in testing) was suggested by Mario Luzeiro! So without him this release would not happen!
To add Bazaar support I also did what I wanted to do a lot time ago: finally I did refactored the plugin to make adding new SCMs easier! This also made the code more clear and I hope more bug-proof.
Another breaking feature was suggested by Blaž Podržaj. Thanks to him new release allows specifying on creation and on deletion scripts. These scripts can be used for preparing repositories for usage and archiving repositories before deleting. By the way, thanks also to Jonas Götze for help in improving scripts!
These scripts can do the same what
hooks options introduced in the previous version do... Therefore hooks now should be treated obsolete and one using it should switch to on creation script (check this page how)! In one of further versions the
hooks support may be removed...
The last feature was needed by me but you can find it useful too if you use my Project Alias plugin. New version is able to rename repository when project identifier is renamed. Please note that this will also change repository access URL (old repository URL will stop working)! That is be sure to notify users before the change!
Also in this version other smaller improvements and bug fixes were made...
That seems to be all!.. Write me, suggest me new features! Let’s make this plugin better!
And thanks for using it!
SCM Creator (+Github): SVN access URL change (2 comments)
As I had mentioned some time ago I changed the project identifier from the obsolete
svn to more correct and SEO friendly
scm-creator! Thanks to my another plugin old URLs will still work because the
svn identifier is now an alias. I have also added the alias
redmine-scm (similar to the plugin’s internal ID)...
Unfortunately this does not apply to SVN URLs - old SVN links stopped to work! Sorry for this!
New SVN URL is: http://svn.s-andy.com/scm-creator
To update the URL in your SVN working copy do:
$ svn switch --relocate http://svn.s-andy.com/redmine-svn http://svn.s-andy.com/scm-creator
http://svn.s-andy.com/redmine-svn- old URL
http://svn.s-andy.com/scm-creator- new URL
This change also precedes new SCM Creator release!.. So !
The code of the plugin has been refactored: HTML code (the Facebook “Like” button code) has been transfered to
app/views (this way it can be easily modified now) and
LikeHelper has been created to hold custom view functions.
These changes also resulted in other improvements... Among them is that now users are not required to patch files! The plugin is distributed with the pre-patched files in it (however for Redmine 1.0.x they should be downloaded separately).
Also this version includes the Spanish translation from Txinto Vaz (thanks, Txinto)!
Sometimes Meta description looked really awful with the Textile code in it! Of course, this depended on the text but I really wanted it to be clear and readable! It appeared that it was not easy to fix...
The remove of the Textile code led to the huge plugin code refactoring what, I believe, made the plugin better and more flexible! Thus in the new version the plugin automatically adds Meta keywords using words which appear most often in the page content.
However I’m not sure how accurate are keywords determined in this way... You probably take this into account before upgrade! Anyway, I believe, they are better than “issue,bug,tracking”... Also determining keywords takes additional time and, again, not sure how much more. Please report any issues you experience with this new release.
For full list of changes check page: 0.1.0.
Many of my Redmine and ChiliProject plugins changed their original ideas. Among them are - SVN Creator which now supports Git and Mercurial and therefore has been renamed into the SCM Creator, Google Ads which allows defining custom content for Redmine hooks and is to be renamed into Hooks manager etc. For all of them, as it appeared later, I chose the wrong project identifiers. And most Redmine users know that it can’t be changed...
So what’s next? Use that insufficient identifiers for historical reasons? Copy/move projects? Change the identifiers directly in the database?.. I would do the last if it did not make external links dead! That are the issues faced by many other Redmine users, as it appeared.
Well... You would not loose external links if there was a possibility to have the previous identifier as an alias so both identifiers worked at the same time. Having project identifier aliases seemed to be a good idea anyway (not sure what for else it would be useful however)... So the idea transformed into project identifier aliases with the possibility to choose the main identifier. All links with old and new identifiers work fine! But project links are generated using only the primary project identifier. For SEO the pages accessed using aliases contain
<link rel="canonical" ... /> (this is what was not tested well!).
I can’t be sure it works without issues however! It does on my test Redmine! But I have not installed it on the production yet... That’s because with changed identifiers I won’t be able to access SVN repositories. At least. As a workaround I added a hook which can be used to change/fix things dependent on identifiers but I have not added support for it in the SCM creator yet... I also plan to patch Redmine.pm to add support for aliases...
So meanwhile you can help me testing it. I believe repository names is the only issue! But... !..
The idea of this plugin came to me when I needed to move my projects from one Redmine hosting site to another (my own). Till that moment my projects were alive already for some time. As it usually is I added many external links to my projects - on Redmine.org, in some forums there and on other sites, in some E-Mails sent to users and friends, in social networks etc. If some of them could be fixed the others could not. If for some of them it was a metter of SEO and rankings for others it was a metter of access.
So I decided to write this plugin...
This plugin will be useful for both - owners of the hosting site project leaves and for owners of the project.
For hosting site it will be useful because:
- Gives control over content shown to users who came onto the dead page;
- Allows redirecting users to a similar project or projects listing;
- Allows not to lose page ranks.
For project owners it will be useful because:
- Allows explaining the reason of project closure;
- Allows redirecting to a new project page.
To supply this the plugin supports the following modes:
- No redirection mode: in this mode the plugin just shows the specified message.
- Redirect to URL: in this mode the plugin redirects to the specified URL.
- Redirect to Redmine/ChiliProject: in this mode the plugin “transparently” redirects to another Redmine/ChiliProject.
Updated my Red-Andy theme! List of “visual” changes you can find here. They include:
- In my opinion:
Quotes now look much better
- Code now is
- Wiki lists now have more space (between rows)
- Wiki TOC now has indents
- Styled associated revisions (changesets)
Should mention the following people who helped me in finding bugs and testing: Tim Lin and Ivan Cenov.
Also available in: Atom