As a side, yet related, note, has any of you looked into the Atlassian suite (http://www.atlassian.com/)? We purchased it for work about a year ago and have been very pleased. They have a free license for open source projects (http://www.atlassian.com/opensource/).
Just an idea to be filed away under "options".
@Ed It's been upgraded to the latest version of Trac. GUI-wise, this doesn't change much. I actually quite like trac's GUI, and the other point you brought up are a matter of core team / community involvement, which as I hope is clear we're improving.
What I'm going to do in the not-too-distant future is set up mirroring SVN to github to let people unsure about git have a try...
As it wassaid before - main problem and task isn't technological issude, but methodological. Without appropriatechanging of development model (if it's needed) changing only SCM will do less than nothing:
1. Branch merging works nice in SVN, if developer don't forget mantra "Merge ofteb, merge fast"
2. Chaos of partially-finished brances in any DCVS give us all one more headache - "Where is the best branch for me?"
3. As mentioned also - why even don't see at Mercurial (well-designed, smartly-implemented), which I see as a better choice in DCVS world vs Git (which was born as a mix of "home-made code" Perl+shell+...)
DCVS in coomon plays welll in situation of
1. a lot of developers,
2. which implements unrelated and independent changes
10-15 authors (with community-commiters) isn't a big problem for well-organized work with "classic" VCS
On http://www.BrainDash.com/community/, we use a number of plugins. Some we've written ourselves, some we've obtained from the community. Our own plugins, CoReg and AutoLogin provide us with a single sign on. friend_request makes friends a 2 way thing, rather than the default (which is more like 'fans' than friends) and sticky_widgets means I can, as an administrator pretty much control what profiles look like. That's hugely important as I may well disable some widget plugins and replace them with different ones and I don't want users to see the dreaded broken plugin widget.
I've also written a few proprietory plugins which aren't available to the community, BD_Terms which changes certain core terms in the languages pages, that has to be the first plugin. BD_Groups, which provides XML-RPC and XML interfaces to groups, BD_Scores which adds a widget to profiles to show your scores on our Third Party Site and BD_theme, which changes the stylesheet and a lot of the elgg view's to look like its part of www.braindash.com.
I'll let you know when I have a week spare. -.-
adultslike.me uses so many plugins and I don't really think we could do without any of them. I've modified most of them in some ways, though, so the functionality (either backend or frontend) is different to most other sites...
I have a folder crammed full of diff files so I can keep pace when there are updates to be had.
It's almost a nightmare. Except I enjoy it. :|
However, back to the topic...
vazco's topbar plugin is probably the most useful. By far. It's allowed me to use elgg's builtin features - groups, pages - to a degree I wouldn't otherwise.
I also love izap_videos, tidypics, and autodash. :)
I'll come back and add links when I have more time, if needed.
I think this could be worth discussing. I've seen a few cases of plugins in the full elgg distribution where the custom styles in each mod are duplicating styles that are set in the core css file. It would be nice to see a more consistent style driven from the core, so someone who isn't a css expert could subtly change the core theme without breaking the overall look and feel. Someone with better css skills probably should be able to handle the additional complication of changing the plugin styles on a more ad-hoc basis.
Although from what i've seen over the last few releases everything is getting better and better
Also one example of fix i've personally made to my theme's css (that overrides the core - that's i've been meaning to send to pete) is:
.input-checkboxes {
background-color: #252525;
border-color:#252525;
}
.contentWrapper, .input-checkboxes {
background-color: #1C1C1C;
border-color:#1C1C1C;
}
.input-radio {
background-color: #252525;
border-color:#252525;
}
.contentWrapper, .input-radio {
background-color: #1C1C1C;
border-color:#1C1C1C;
}
This is a small basic change which lets IE6 correctly set the background colour of checkboxes and radio buttons (please don't get me started on how much I dislike IE6, but a lot of my users still use it), but it's just a small example of how small changes & feedback over time can improve consistency for all users.
It looks to me as though the original way of doing things was to have a single css.php file, whereas subsequently that method has evolved to have separate css.php pages for each plugin. What has never happened (by the looks of it) is breaking up the original css.php page, to populate the core plugins.
I would suggest, with heinsight, that the best option would be to have the core classes in the main css.php page, and each plugin just define the ones that relate to that.
As an extension of that, there could be more attention paid to inheriting classes from the base, rather than redefining them, so that subsequent changes to the style wouldn't require quite so much work.
I've attempted to do that in my own copy, by placing PHP variables in various places, then defining them centrally, so that the styles can change quickly and easily, but to do it properly is a lot of work. If anyone want's to volunteer, great, otherwise I think we just need to ensure new stuff follows the new style and leave the old stuff alone.
Simon
Related trac ticket: https://trac.elgg.org/elgg/ticket/952
I agree with Don. The current core css makes it difficult to write a plugin without writing custom css. There are very few elements that are generic that can be used. This then makes it difficult to write themes since every plugin has it's own css.
I'd like to see the core css at least define a set of primitives and then have plugin authors encouraged to use them.
I think this could be worth discussing. I've seen a few cases of plugins in the full elgg distribution where the custom styles in each mod are duplicating styles that are set in the core css file. It would be nice to see a more consistent style driven from the core, so someone who isn't a css expert could subtly change the core theme without breaking the overall look and feel. Someone with better css skills probably should be able to handle the additional complication of changing the plugin styles on a more ad-hoc basis.
Although from what i've seen over the last few releases everything is getting better and better
Also one example of fix i've personally made to my theme's css (that overrides the core - that's i've been meaning to send to pete) is:
.input-checkboxes {
background-color: #252525;
border-color:#252525;
}
.contentWrapper, .input-checkboxes {
background-color: #1C1C1C;
border-color:#1C1C1C;
}
.input-radio {
background-color: #252525;
border-color:#252525;
}
.contentWrapper, .input-radio {
background-color: #1C1C1C;
border-color:#1C1C1C;
}
This is a small basic change which lets IE6 correctly set the background colour of checkboxes and radio buttons (please don't get me started on how much I dislike IE6, but a lot of my users still use it), but it's just a small example of how small changes & feedback over time can improve consistency for all users.
It looks to me as though the original way of doing things was to have a single css.php file, whereas subsequently that method has evolved to have separate css.php pages for each plugin. What has never happened (by the looks of it) is breaking up the original css.php page, to populate the core plugins.
I would suggest, with heinsight, that the best option would be to have the core classes in the main css.php page, and each plugin just define the ones that relate to that.
As an extension of that, there could be more attention paid to inheriting classes from the base, rather than redefining them, so that subsequent changes to the style wouldn't require quite so much work.
I've attempted to do that in my own copy, by placing PHP variables in various places, then defining them centrally, so that the styles can change quickly and easily, but to do it properly is a lot of work. If anyone want's to volunteer, great, otherwise I think we just need to ensure new stuff follows the new style and leave the old stuff alone.
Simon
Related trac ticket: https://trac.elgg.org/elgg/ticket/952
I agree with Don. The current core css makes it difficult to write a plugin without writing custom css. There are very few elements that are generic that can be used. This then makes it difficult to write themes since every plugin has it's own css.
I'd like to see the core css at least define a set of primitives and then have plugin authors encouraged to use them.
*points to 'featured plugins' discussion in this group*
What Cash mentioned is good.
Even though I have only slightly dipped into making a plugin so far, putting up updates for something left a string of extra entries that were unneeded. would be nice to have a consolidated place for a plug with the exception for when a plug deals with two different versions of ELGG.
Hmm ;=-( I cannot find my notes ( my most important elgg ext backup drive fell and broke ) I will have to remember what was posted before and rewrite it.
aha ;-)
http://elggtest.ensci.us/plugins/ -- is where i put my generated master plugins listing so that i can do quick searches. that is produced by parsing all the pages ?offset=##, storing the items in an array, which can be sorted by date, names , made array_unique... to do diff reports so i can see "versions" and so on...
I've written 2 patches, one to make simplecache use a subdirectory of HTTP_HOST within the data directory, and one to allow code in settings.php to add a prefix, after the site prefix, to the core entitiy tables. So whereas normally entities, users_entity and sites_entity normally get prefixed with something like 'elgg' to give elggentities, elggusers_entity and elggsites_entity, on my system, depending on vhost, that becomes something different. So I have elggbdsites_entity on one site and elggeqsites_entity on another. That allows me to virtualise my instance of elgg.
I've written 2 patches, one to make simplecache use a subdirectory of HTTP_HOST within the data directory, and one to allow code in settings.php to add a prefix, after the site prefix, to the core entitiy tables. So whereas normally entities, users_entity and sites_entity normally get prefixed with something like 'elgg' to give elggentities, elggusers_entity and elggsites_entity, on my system, depending on vhost, that becomes something different. So I have elggbdsites_entity on one site and elggeqsites_entity on another. That allows me to virtualise my instance of elgg.
info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by RaĆ¼l Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.