Just a note to say that the Redirect component is now fixed (seemed to have some issues previously) and fully refactored. Write up can be found here if you haven't seen it already:
There are two good suggestions from the forum regarding this component. First is to record the number of hits on a recorded 404 to help with triage. Second is to add a simple but optional selector for an existing menu link in the new url. Neither should be particularly difficult to implement.
Plugins manager is fully refactored. All plugin XML files have had their <params> upgraded to <fields> and, like with templates and menus, it's possible to have any number of option panes (modules is yet to have this added). I altered the ordering processing a bit on plugins to be non-sequential. This will make it easier to keep those that need to fire first first, and those last last (if that makes sense).
A couple of things need to be looked at and done regarding plugins:
1. We need to check the ordering of the core plugins. For example, system redirect and cache should be firing early; content pagebreak should be firing last.
2. Plugins now support folder based installation just like modules. Personally I think we should commit to the new format and not mix-and-match. A volunteer to move them around an assemble a patch would be appreciated.
3. Language strings need to be updated in all the plugin XML files. The Debug plugin is a good example of what to aim for. A volunteer for this would also be appreciated.
4. Plugins language files seem to be inconsistently represented in both the frontend and the backend. I seem to recall we had some discussion about this but can't for the life of me remember what the conclusion was. I think it should be one or the other.
To date the following backend extensions have been standardised (whether the "standard" is perfect or not remains to be seen, but at least the code is highly consistent):
Weblinks Users Templates Search Redirect Plugins Newsfeeds Languages (I think - need to check) Config (I think - need to check) Content
I'll be into Modules next week and also attend to some problem areas in Menus. If anyone has had a go at refactoring any of the other backend components (in line with those listed above) please let me know.
Here is a quick shortlist of other jobs people might like to pick up on:
1. We are moving away from JParameter to JForm. As such, we need to check that all existing JParameter elements are covered by JForm fields.
2. Module XML files need to be changed from using <params> to <fields>. This is generally just a search and replace but the name of the param type and the field type may vary slightly (probably just in the inflection).
3. Module language strings need to be standardised.
4. All component, plugin, module, language and template manifest/install XML file should be fully updated as if they where installable. That includes a correct <files> and language list.
These aren't terribly glamorous jobs but they are important. We've suffered from the code being inconsistent for too long and it's one of the reasons behind getting bogged down in these long release cycles (among other things, I know, I know). Once we have code standardised, it's going to be a heck of a lot easier to get into the freaky cool stuff we all know is possible (not to mention set the best possible example for community developers to follow).
Thanks to those who have chipped in with various things over the last couple of weeks - it's been appreciated.
> Just a note to say that the Redirect component is now fixed (seemed to
> have some issues previously) and fully refactored. Write up can be
> found here if you haven't seen it already:
> There are two good suggestions from the forum regarding this
> component. First is to record the number of hits on a recorded 404 to
> help with triage. Second is to add a simple but optional selector for
> an existing menu link in the new url. Neither should be particularly
> difficult to implement.
> Plugins manager is fully refactored. All plugin XML files have had
> their <params> upgraded to <fields> and, like with templates and
> menus, it's possible to have any number of option panes (modules is
> yet to have this added). I altered the ordering processing a bit on
> plugins to be non-sequential. This will make it easier to keep those
> that need to fire first first, and those last last (if that makes
> sense).
> A couple of things need to be looked at and done regarding plugins:
> 1. We need to check the ordering of the core plugins. For example,
> system redirect and cache should be firing early; content pagebreak
> should be firing last.
> 2. Plugins now support folder based installation just like modules.
> Personally I think we should commit to the new format and not
> mix-and-match. A volunteer to move them around an assemble a patch
> would be appreciated.
> 3. Language strings need to be updated in all the plugin XML files.
> The Debug plugin is a good example of what to aim for. A volunteer
> for this would also be appreciated.
> 4. Plugins language files seem to be inconsistently represented in
> both the frontend and the backend. I seem to recall we had some
> discussion about this but can't for the life of me remember what the
> conclusion was. I think it should be one or the other.
> To date the following backend extensions have been standardised
> (whether the "standard" is perfect or not remains to be seen, but at
> least the code is highly consistent):
> Weblinks
> Users
> Templates
> Search
> Redirect
> Plugins
> Newsfeeds
> Languages (I think - need to check)
> Config (I think - need to check)
> Content
> I'll be into Modules next week and also attend to some problem areas
> in Menus. If anyone has had a go at refactoring any of the other
> backend components (in line with those listed above) please let me
> know.
> Here is a quick shortlist of other jobs people might like to pick up on:
> 1. We are moving away from JParameter to JForm. As such, we need to
> check that all existing JParameter elements are covered by JForm
> fields.
> 2. Module XML files need to be changed from using <params> to
> <fields>. This is generally just a search and replace but the name of
> the param type and the field type may vary slightly (probably just in
> the inflection).
> 3. Module language strings need to be standardised.
> 4. All component, plugin, module, language and template
> manifest/install XML file should be fully updated as if they where
> installable. That includes a correct <files> and language list.
> These aren't terribly glamorous jobs but they are important. We've
> suffered from the code being inconsistent for too long and it's one of
> the reasons behind getting bogged down in these long release cycles
> (among other things, I know, I know). Once we have code standardised,
> it's going to be a heck of a lot easier to get into the freaky cool
> stuff we all know is possible (not to mention set the best possible
> example for community developers to follow).
> Thanks to those who have chipped in with various things over the last
> couple of weeks - it's been appreciated.
I already completed #2 on plugins but was unable to merge my work.
(because of either Subversion's stupidity or mine) It's in the
plugin_dirs branch so you can start from there.
On 23 Nov, 20:32, Amy Stephen <amystep...@gmail.com> wrote:
> Fotis Evangelou, Stian Didriksen and I are willing to help with the
> Plugin changes needed.
> If you could let us know where to work and recommend someone
> (yourself?) to help with questions, we will get started on your list.
> Thanks!
> Amy
> On 13 Nov, 06:25, Andrew Eddie <mambob...@gmail.com> wrote:
> > Just a note to say that the Redirect component is now fixed (seemed to
> > have some issues previously) and fully refactored. Write up can be
> > found here if you haven't seen it already:
> > There are two good suggestions from the forum regarding this
> > component. First is to record the number of hits on a recorded 404 to
> > help with triage. Second is to add a simple but optional selector for
> > an existing menu link in the new url. Neither should be particularly
> > difficult to implement.
> > Plugins manager is fully refactored. All plugin XML files have had
> > their <params> upgraded to <fields> and, like with templates and
> > menus, it's possible to have any number of option panes (modules is
> > yet to have this added). I altered the ordering processing a bit on
> > plugins to be non-sequential. This will make it easier to keep those
> > that need to fire first first, and those last last (if that makes
> > sense).
> > A couple of things need to be looked at and done regarding plugins:
> > 1. We need to check the ordering of the core plugins. For example,
> > system redirect and cache should be firing early; content pagebreak
> > should be firing last.
> > 2. Plugins now support folder based installation just like modules.
> > Personally I think we should commit to the new format and not
> > mix-and-match. A volunteer to move them around an assemble a patch
> > would be appreciated.
> > 3. Language strings need to be updated in all the plugin XML files.
> > The Debug plugin is a good example of what to aim for. A volunteer
> > for this would also be appreciated.
> > 4. Plugins language files seem to be inconsistently represented in
> > both the frontend and the backend. I seem to recall we had some
> > discussion about this but can't for the life of me remember what the
> > conclusion was. I think it should be one or the other.
> > To date the following backend extensions have been standardised
> > (whether the "standard" is perfect or not remains to be seen, but at
> > least the code is highly consistent):
> > Weblinks
> > Users
> > Templates
> > Search
> > Redirect
> > Plugins
> > Newsfeeds
> > Languages (I think - need to check)
> > Config (I think - need to check)
> > Content
> > I'll be into Modules next week and also attend to some problem areas
> > in Menus. If anyone has had a go at refactoring any of the other
> > backend components (in line with those listed above) please let me
> > know.
> > Here is a quick shortlist of other jobs people might like to pick up on:
> > 1. We are moving away from JParameter to JForm. As such, we need to
> > check that all existing JParameter elements are covered by JForm
> > fields.
> > 2. Module XML files need to be changed from using <params> to
> > <fields>. This is generally just a search and replace but the name of
> > the param type and the field type may vary slightly (probably just in
> > the inflection).
> > 3. Module language strings need to be standardised.
> > 4. All component, plugin, module, language and template
> > manifest/install XML file should be fully updated as if they where
> > installable. That includes a correct <files> and language list.
> > These aren't terribly glamorous jobs but they are important. We've
> > suffered from the code being inconsistent for too long and it's one of
> > the reasons behind getting bogged down in these long release cycles
> > (among other things, I know, I know). Once we have code standardised,
> > it's going to be a heck of a lot easier to get into the freaky cool
> > stuff we all know is possible (not to mention set the best possible
> > example for community developers to follow).
> > Thanks to those who have chipped in with various things over the last
> > couple of weeks - it's been appreciated.
> I already completed #2 on plugins but was unable to merge my work.
> (because of either Subversion's stupidity or mine) It's in the
> plugin_dirs branch so you can start from there.
> On 23 Nov, 20:32, Amy Stephen <amystep...@gmail.com> wrote:
> > Andrew -
> > Fotis Evangelou, Stian Didriksen and I are willing to help with the
> > Plugin changes needed.
> > If you could let us know where to work and recommend someone
> > (yourself?) to help with questions, we will get started on your list.
> > Thanks!
> > Amy
> > On 13 Nov, 06:25, Andrew Eddie <mambob...@gmail.com> wrote:
> > > Just a note to say that the Redirect component is now fixed (seemed to
> > > have some issues previously) and fully refactored. Write up can be
> > > found here if you haven't seen it already:
> > > There are two good suggestions from the forum regarding this
> > > component. First is to record the number of hits on a recorded 404 to
> > > help with triage. Second is to add a simple but optional selector for
> > > an existing menu link in the new url. Neither should be particularly
> > > difficult to implement.
> > > Plugins manager is fully refactored. All plugin XML files have had
> > > their <params> upgraded to <fields> and, like with templates and
> > > menus, it's possible to have any number of option panes (modules is
> > > yet to have this added). I altered the ordering processing a bit on
> > > plugins to be non-sequential. This will make it easier to keep those
> > > that need to fire first first, and those last last (if that makes
> > > sense).
> > > A couple of things need to be looked at and done regarding plugins:
> > > 1. We need to check the ordering of the core plugins. For example,
> > > system redirect and cache should be firing early; content pagebreak
> > > should be firing last.
> > > 2. Plugins now support folder based installation just like modules.
> > > Personally I think we should commit to the new format and not
> > > mix-and-match. A volunteer to move them around an assemble a patch
> > > would be appreciated.
> > > 3. Language strings need to be updated in all the plugin XML files.
> > > The Debug plugin is a good example of what to aim for. A volunteer
> > > for this would also be appreciated.
> > > 4. Plugins language files seem to be inconsistently represented in
> > > both the frontend and the backend. I seem to recall we had some
> > > discussion about this but can't for the life of me remember what the
> > > conclusion was. I think it should be one or the other.
> > > To date the following backend extensions have been standardised
> > > (whether the "standard" is perfect or not remains to be seen, but at
> > > least the code is highly consistent):
> > > Weblinks
> > > Users
> > > Templates
> > > Search
> > > Redirect
> > > Plugins
> > > Newsfeeds
> > > Languages (I think - need to check)
> > > Config (I think - need to check)
> > > Content
> > > I'll be into Modules next week and also attend to some problem areas
> > > in Menus. If anyone has had a go at refactoring any of the other
> > > backend components (in line with those listed above) please let me
> > > know.
> > > Here is a quick shortlist of other jobs people might like to pick up on:
> > > 1. We are moving away from JParameter to JForm. As such, we need to
> > > check that all existing JParameter elements are covered by JForm
> > > fields.
> > > 2. Module XML files need to be changed from using <params> to
> > > <fields>. This is generally just a search and replace but the name of
> > > the param type and the field type may vary slightly (probably just in
> > > the inflection).
> > > 3. Module language strings need to be standardised.
> > > 4. All component, plugin, module, language and template
> > > manifest/install XML file should be fully updated as if they where
> > > installable. That includes a correct <files> and language list.
> > > These aren't terribly glamorous jobs but they are important. We've
> > > suffered from the code being inconsistent for too long and it's one of
> > > the reasons behind getting bogged down in these long release cycles
> > > (among other things, I know, I know). Once we have code standardised,
> > > it's going to be a heck of a lot easier to get into the freaky cool
> > > stuff we all know is possible (not to mention set the best possible
> > > example for community developers to follow).
> > > Thanks to those who have chipped in with various things over the last
> > > couple of weeks - it's been appreciated.
>> I already completed #2 on plugins but was unable to merge my work.
>> (because of either Subversion's stupidity or mine) It's in the
>> plugin_dirs branch so you can start from there.
>> On 23 Nov, 20:32, Amy Stephen <amystep...@gmail.com> wrote:
>> > Andrew -
>> > Fotis Evangelou, Stian Didriksen and I are willing to help with the
>> > Plugin changes needed.
>> > If you could let us know where to work and recommend someone
>> > (yourself?) to help with questions, we will get started on your list.
>> > Thanks!
>> > Amy
>> > On 13 Nov, 06:25, Andrew Eddie <mambob...@gmail.com> wrote:
>> > > Just a note to say that the Redirect component is now fixed (seemed to
>> > > have some issues previously) and fully refactored. Write up can be
>> > > found here if you haven't seen it already:
>> > > There are two good suggestions from the forum regarding this
>> > > component. First is to record the number of hits on a recorded 404 to
>> > > help with triage. Second is to add a simple but optional selector for
>> > > an existing menu link in the new url. Neither should be particularly
>> > > difficult to implement.
>> > > Plugins manager is fully refactored. All plugin XML files have had
>> > > their <params> upgraded to <fields> and, like with templates and
>> > > menus, it's possible to have any number of option panes (modules is
>> > > yet to have this added). I altered the ordering processing a bit on
>> > > plugins to be non-sequential. This will make it easier to keep those
>> > > that need to fire first first, and those last last (if that makes
>> > > sense).
>> > > A couple of things need to be looked at and done regarding plugins:
>> > > 1. We need to check the ordering of the core plugins. For example,
>> > > system redirect and cache should be firing early; content pagebreak
>> > > should be firing last.
>> > > 2. Plugins now support folder based installation just like modules.
>> > > Personally I think we should commit to the new format and not
>> > > mix-and-match. A volunteer to move them around an assemble a patch
>> > > would be appreciated.
>> > > 3. Language strings need to be updated in all the plugin XML files.
>> > > The Debug plugin is a good example of what to aim for. A volunteer
>> > > for this would also be appreciated.
>> > > 4. Plugins language files seem to be inconsistently represented in
>> > > both the frontend and the backend. I seem to recall we had some
>> > > discussion about this but can't for the life of me remember what the
>> > > conclusion was. I think it should be one or the other.
>> > > To date the following backend extensions have been standardised
>> > > (whether the "standard" is perfect or not remains to be seen, but at
>> > > least the code is highly consistent):
>> > > Weblinks
>> > > Users
>> > > Templates
>> > > Search
>> > > Redirect
>> > > Plugins
>> > > Newsfeeds
>> > > Languages (I think - need to check)
>> > > Config (I think - need to check)
>> > > Content
>> > > I'll be into Modules next week and also attend to some problem areas
>> > > in Menus. If anyone has had a go at refactoring any of the other
>> > > backend components (in line with those listed above) please let me
>> > > know.
>> > > Here is a quick shortlist of other jobs people might like to pick up on:
>> > > 1. We are moving away from JParameter to JForm. As such, we need to
>> > > check that all existing JParameter elements are covered by JForm
>> > > fields.
>> > > 2. Module XML files need to be changed from using <params> to
>> > > <fields>. This is generally just a search and replace but the name of
>> > > the param type and the field type may vary slightly (probably just in
>> > > the inflection).
>> > > 3. Module language strings need to be standardised.
>> > > 4. All component, plugin, module, language and template
>> > > manifest/install XML file should be fully updated as if they where
>> > > installable. That includes a correct <files> and language list.
>> > > These aren't terribly glamorous jobs but they are important. We've
>> > > suffered from the code being inconsistent for too long and it's one of
>> > > the reasons behind getting bogged down in these long release cycles
>> > > (among other things, I know, I know). Once we have code standardised,
>> > > it's going to be a heck of a lot easier to get into the freaky cool
>> > > stuff we all know is possible (not to mention set the best possible
>> > > example for community developers to follow).
>> > > Thanks to those who have chipped in with various things over the last
>> > > couple of weeks - it's been appreciated.
> >> I already completed #2 on plugins but was unable to merge my work.
> >> (because of either Subversion's stupidity or mine) It's in the
> >> plugin_dirs branch so you can start from there.
> >> On 23 Nov, 20:32, Amy Stephen <amystep...@gmail.com> wrote:
> >> > Andrew -
> >> > Fotis Evangelou, Stian Didriksen and I are willing to help with the
> >> > Plugin changes needed.
> >> > If you could let us know where to work and recommend someone
> >> > (yourself?) to help with questions, we will get started on your list.
> >> > Thanks!
> >> > Amy
> >> > On 13 Nov, 06:25, Andrew Eddie <mambob...@gmail.com> wrote:
> >> > > Just a note to say that the Redirect component is now fixed (seemed
> to
> >> > > have some issues previously) and fully refactored. Write up can be
> >> > > found here if you haven't seen it already:
> >> > > There are two good suggestions from the forum regarding this
> >> > > component. First is to record the number of hits on a recorded 404
> to
> >> > > help with triage. Second is to add a simple but optional selector
> for
> >> > > an existing menu link in the new url. Neither should be
> particularly
> >> > > difficult to implement.
> >> > > Plugins manager is fully refactored. All plugin XML files have had
> >> > > their <params> upgraded to <fields> and, like with templates and
> >> > > menus, it's possible to have any number of option panes (modules is
> >> > > yet to have this added). I altered the ordering processing a bit on
> >> > > plugins to be non-sequential. This will make it easier to keep
> those
> >> > > that need to fire first first, and those last last (if that makes
> >> > > sense).
> >> > > A couple of things need to be looked at and done regarding plugins:
> >> > > 1. We need to check the ordering of the core plugins. For example,
> >> > > system redirect and cache should be firing early; content pagebreak
> >> > > should be firing last.
> >> > > 2. Plugins now support folder based installation just like modules.
> >> > > Personally I think we should commit to the new format and not
> >> > > mix-and-match. A volunteer to move them around an assemble a patch
> >> > > would be appreciated.
> >> > > 3. Language strings need to be updated in all the plugin XML files.
> >> > > The Debug plugin is a good example of what to aim for. A volunteer
> >> > > for this would also be appreciated.
> >> > > 4. Plugins language files seem to be inconsistently represented in
> >> > > both the frontend and the backend. I seem to recall we had some
> >> > > discussion about this but can't for the life of me remember what the
> >> > > conclusion was. I think it should be one or the other.
> >> > > To date the following backend extensions have been standardised
> >> > > (whether the "standard" is perfect or not remains to be seen, but at
> >> > > least the code is highly consistent):
> >> > > Weblinks
> >> > > Users
> >> > > Templates
> >> > > Search
> >> > > Redirect
> >> > > Plugins
> >> > > Newsfeeds
> >> > > Languages (I think - need to check)
> >> > > Config (I think - need to check)
> >> > > Content
> >> > > I'll be into Modules next week and also attend to some problem areas
> >> > > in Menus. If anyone has had a go at refactoring any of the other
> >> > > backend components (in line with those listed above) please let me
> >> > > know.
> >> > > Here is a quick shortlist of other jobs people might like to pick up
> on:
> >> > > 1. We are moving away from JParameter to JForm. As such, we need to
> >> > > check that all existing JParameter elements are covered by JForm
> >> > > fields.
> >> > > 2. Module XML files need to be changed from using <params> to
> >> > > <fields>. This is generally just a search and replace but the name
> of
> >> > > the param type and the field type may vary slightly (probably just
> in
> >> > > the inflection).
> >> > > 3. Module language strings need to be standardised.
> >> > > 4. All component, plugin, module, language and template
> >> > > manifest/install XML file should be fully updated as if they where
> >> > > installable. That includes a correct <files> and language list.
> >> > > These aren't terribly glamorous jobs but they are important. We've
> >> > > suffered from the code being inconsistent for too long and it's one
> of
> >> > > the reasons behind getting bogged down in these long release cycles
> >> > > (among other things, I know, I know). Once we have code
> standardised,
> >> > > it's going to be a heck of a lot easier to get into the freaky cool
> >> > > stuff we all know is possible (not to mention set the best possible
> >> > > example for community developers to follow).
> >> > > Thanks to those who have chipped in with various things over the
> last
> >> > > couple of weeks - it's been appreciated.
Sam will undoubtedly get to that when he has a free moment.
And before you say it, yes, there is a better system coming soon.
You'll hear about it Saturday week.
When you do go gunning, please keep us updated on list and also
remember it's your responsibility to keep your own branches sync'd
with trunk. I recommend doing it daily.
>> >> I already completed #2 on plugins but was unable to merge my work.
>> >> (because of either Subversion's stupidity or mine) It's in the
>> >> plugin_dirs branch so you can start from there.
>> >> On 23 Nov, 20:32, Amy Stephen <amystep...@gmail.com> wrote:
>> >> > Andrew -
>> >> > Fotis Evangelou, Stian Didriksen and I are willing to help with the
>> >> > Plugin changes needed.
>> >> > If you could let us know where to work and recommend someone
>> >> > (yourself?) to help with questions, we will get started on your list.
>> >> > Thanks!
>> >> > Amy
>> >> > On 13 Nov, 06:25, Andrew Eddie <mambob...@gmail.com> wrote:
>> >> > > Just a note to say that the Redirect component is now fixed (seemed
>> >> > > to
>> >> > > have some issues previously) and fully refactored. Write up can be
>> >> > > found here if you haven't seen it already:
>> >> > > There are two good suggestions from the forum regarding this
>> >> > > component. First is to record the number of hits on a recorded 404
>> >> > > to
>> >> > > help with triage. Second is to add a simple but optional selector
>> >> > > for
>> >> > > an existing menu link in the new url. Neither should be
>> >> > > particularly
>> >> > > difficult to implement.
>> >> > > Plugins manager is fully refactored. All plugin XML files have had
>> >> > > their <params> upgraded to <fields> and, like with templates and
>> >> > > menus, it's possible to have any number of option panes (modules is
>> >> > > yet to have this added). I altered the ordering processing a bit
>> >> > > on
>> >> > > plugins to be non-sequential. This will make it easier to keep
>> >> > > those
>> >> > > that need to fire first first, and those last last (if that makes
>> >> > > sense).
>> >> > > A couple of things need to be looked at and done regarding plugins:
>> >> > > 1. We need to check the ordering of the core plugins. For example,
>> >> > > system redirect and cache should be firing early; content pagebreak
>> >> > > should be firing last.
>> >> > > 2. Plugins now support folder based installation just like modules.
>> >> > > Personally I think we should commit to the new format and not
>> >> > > mix-and-match. A volunteer to move them around an assemble a patch
>> >> > > would be appreciated.
>> >> > > 3. Language strings need to be updated in all the plugin XML files.
>> >> > > The Debug plugin is a good example of what to aim for. A volunteer
>> >> > > for this would also be appreciated.
>> >> > > 4. Plugins language files seem to be inconsistently represented in
>> >> > > both the frontend and the backend. I seem to recall we had some
>> >> > > discussion about this but can't for the life of me remember what
>> >> > > the
>> >> > > conclusion was. I think it should be one or the other.
>> >> > > To date the following backend extensions have been standardised
>> >> > > (whether the "standard" is perfect or not remains to be seen, but
>> >> > > at
>> >> > > least the code is highly consistent):
>> >> > > Weblinks
>> >> > > Users
>> >> > > Templates
>> >> > > Search
>> >> > > Redirect
>> >> > > Plugins
>> >> > > Newsfeeds
>> >> > > Languages (I think - need to check)
>> >> > > Config (I think - need to check)
>> >> > > Content
>> >> > > I'll be into Modules next week and also attend to some problem
>> >> > > areas
>> >> > > in Menus. If anyone has had a go at refactoring any of the other
>> >> > > backend components (in line with those listed above) please let me
>> >> > > know.
>> >> > > Here is a quick shortlist of other jobs people might like to pick
>> >> > > up on:
>> >> > > 1. We are moving away from JParameter to JForm. As such, we need
>> >> > > to
>> >> > > check that all existing JParameter elements are covered by JForm
>> >> > > fields.
>> >> > > 2. Module XML files need to be changed from using <params> to
>> >> > > <fields>. This is generally just a search and replace but the name
>> >> > > of
>> >> > > the param type and the field type may vary slightly (probably just
>> >> > > in
>> >> > > the inflection).
>> >> > > 3. Module language strings need to be standardised.
>> >> > > 4. All component, plugin, module, language and template
>> >> > > manifest/install XML file should be fully updated as if they where
>> >> > > installable. That includes a correct <files> and language list.
>> >> > > These aren't terribly glamorous jobs but they are important. We've
>> >> > > suffered from the code being inconsistent for too long and it's one
>> >> > > of
>> >> > > the reasons behind getting bogged down in these long release cycles
>> >> > > (among other things, I know, I know). Once we have code
>> >> > > standardised,
>> >> > > it's going to be a heck of a lot easier to get into the freaky cool
>> >> > > stuff we all know is possible (not to mention set the best possible
>> >> > > example for community developers to follow).
>> >> > > Thanks to those who have chipped in with various things over the
>> >> > > last
>> >> > > couple of weeks - it's been appreciated.
> >> >> I already completed #2 on plugins but was unable to merge my work.
> >> >> (because of either Subversion's stupidity or mine) It's in the
> >> >> plugin_dirs branch so you can start from there.
> >> >> On 23 Nov, 20:32, Amy Stephen <amystep...@gmail.com> wrote:
> >> >> > Andrew -
> >> >> > Fotis Evangelou, Stian Didriksen and I are willing to help with the
> >> >> > Plugin changes needed.
> >> >> > If you could let us know where to work and recommend someone
> >> >> > (yourself?) to help with questions, we will get started on your
> list.
> >> >> > Thanks!
> >> >> > Amy
> >> >> > On 13 Nov, 06:25, Andrew Eddie <mambob...@gmail.com> wrote:
> >> >> > > Just a note to say that the Redirect component is now fixed
> (seemed
> >> >> > > to
> >> >> > > have some issues previously) and fully refactored. Write up can
> be
> >> >> > > found here if you haven't seen it already:
> >> >> > > There are two good suggestions from the forum regarding this
> >> >> > > component. First is to record the number of hits on a recorded
> 404
> >> >> > > to
> >> >> > > help with triage. Second is to add a simple but optional
> selector
> >> >> > > for
> >> >> > > an existing menu link in the new url. Neither should be
> >> >> > > particularly
> >> >> > > difficult to implement.
> >> >> > > Plugins manager is fully refactored. All plugin XML files have
> had
> >> >> > > their <params> upgraded to <fields> and, like with templates and
> >> >> > > menus, it's possible to have any number of option panes (modules
> is
> >> >> > > yet to have this added). I altered the ordering processing a bit
> >> >> > > on
> >> >> > > plugins to be non-sequential. This will make it easier to keep
> >> >> > > those
> >> >> > > that need to fire first first, and those last last (if that makes
> >> >> > > sense).
> >> >> > > A couple of things need to be looked at and done regarding
> plugins:
> >> >> > > 1. We need to check the ordering of the core plugins. For
> example,
> >> >> > > system redirect and cache should be firing early; content
> pagebreak
> >> >> > > should be firing last.
> >> >> > > 2. Plugins now support folder based installation just like
> modules.
> >> >> > > Personally I think we should commit to the new format and not
> >> >> > > mix-and-match. A volunteer to move them around an assemble a
> patch
> >> >> > > would be appreciated.
> >> >> > > 3. Language strings need to be updated in all the plugin XML
> files.
> >> >> > > The Debug plugin is a good example of what to aim for. A
> volunteer
> >> >> > > for this would also be appreciated.
> >> >> > > 4. Plugins language files seem to be inconsistently represented
> in
> >> >> > > both the frontend and the backend. I seem to recall we had some
> >> >> > > discussion about this but can't for the life of me remember what
> >> >> > > the
> >> >> > > conclusion was. I think it should be one or the other.
> >> >> > > To date the following backend extensions have been standardised
> >> >> > > (whether the "standard" is perfect or not remains to be seen, but
> >> >> > > at
> >> >> > > least the code is highly consistent):
> >> >> > > I'll be into Modules next week and also attend to some problem
> >> >> > > areas
> >> >> > > in Menus. If anyone has had a go at refactoring any of the other
> >> >> > > backend components (in line with those listed above) please let
> me
> >> >> > > know.
> >> >> > > Here is a quick shortlist of other jobs people might like to pick
> >> >> > > up on:
> >> >> > > 1. We are moving away from JParameter to JForm. As such, we need
> >> >> > > to
> >> >> > > check that all existing JParameter elements are covered by JForm
> >> >> > > fields.
> >> >> > > 2. Module XML files need to be changed from using <params> to
> >> >> > > <fields>. This is generally just a search and replace but the
> name
> >> >> > > of
> >> >> > > the param type and the field type may vary slightly (probably
> just
> >> >> > > in
> >> >> > > the inflection).
> >> >> > > 3. Module language strings need to be standardised.
> >> >> > > 4. All component, plugin, module, language and template
> >> >> > > manifest/install XML file should be fully updated as if they
> where
> >> >> > > installable. That includes a correct <files> and language list.
> >> >> > > These aren't terribly glamorous jobs but they are important.
> We've
> >> >> > > suffered from the code being inconsistent for too long and it's
> one
> >> >> > > of
> >> >> > > the reasons behind getting bogged down in these long release
> cycles
> >> >> > > (among other things, I know, I know). Once we have code
> >> >> > > standardised,
> >> >> > > it's going to be a heck of a lot easier to get into the freaky
> cool
> >> >> > > stuff we all know is possible (not to mention set the best
> possible
> >> >> > > example for community developers to follow).
> >> >> > > Thanks to those who have chipped in with various things over the
> >> >> > > last
> >> >> > > couple of weeks - it's been appreciated.
My account are indeed "stipsan".
I got enough free time on my hands to get cracking this Friday :)
As for plugins language files location, I recommend using strictly
the /root/languages/ and not using /root/administrator/languages/ for
that at all.
Reason why is that the location of the plugin files isn't on the admin
side, so neither should the language files imo.
On Nov 24, 7:02 pm, JoomlaWorks <joomlawo...@gmail.com> wrote:
I'm a little unsure how to proceed here. Do we just continue working
on that branch then have someone do a "all for one, one for all" merge
to trunk or submit a patch?
I'll just commit to the plugin_dirs branch until further notice just
to get some work done :)
On Nov 25, 9:27 pm, Amy Stephen <amystep...@gmail.com> wrote:
Do you want to do a quick skype meeting with Fotis and myself, and get a
game plan? That might be good. We need to make sure to share our plans in
this thread - and also via the wiki.
http://docs.joomla.org/Refactoring_Plugins
Fotis around? :)
On Fri, Nov 27, 2009 at 5:09 PM, Stian Didriksen <st...@ninjatheme.com>wrote:
> I'm a little unsure how to proceed here. Do we just continue working
> on that branch then have someone do a "all for one, one for all" merge
> to trunk or submit a patch?
> I'll just commit to the plugin_dirs branch until further notice just
> to get some work done :)
> On Nov 25, 9:27 pm, Amy Stephen <amystep...@gmail.com> wrote:
> > Thanks, Sam, for providing access to Fotis, Stian, and myself to
> > Ercan's branch.
There are no hard and fast rules about how you should do this, just
find the best groove that works for you. The end result would be to
create a diff patch that I can drop over the trunk - that would be the
most convenient if it's possible. I recommend merging down from the
trunk daily so you don't get too far out of sync but I don't think
much action is taking place in the files you'll be touching.
> Do you want to do a quick skype meeting with Fotis and myself, and get a
> game plan? That might be good. We need to make sure to share our plans in
> this thread - and also via the wiki.
> http://docs.joomla.org/Refactoring_Plugins
> Fotis around? :)
> On Fri, Nov 27, 2009 at 5:09 PM, Stian Didriksen <st...@ninjatheme.com>
> wrote:
>> I'm a little unsure how to proceed here. Do we just continue working
>> on that branch then have someone do a "all for one, one for all" merge
>> to trunk or submit a patch?
>> I'll just commit to the plugin_dirs branch until further notice just
>> to get some work done :)
>> On Nov 25, 9:27 pm, Amy Stephen <amystep...@gmail.com> wrote:
>> > Thanks, Sam, for providing access to Fotis, Stian, and myself to
>> > Ercan's branch.
Good advice.
We just recently experienced some troubles on a branch on the Nooku FW
where it came too far out of sync with the trunk.
So I'll just make sure I'm up to speed as I think it's better to be
safe than sorry ;)
On Nov 28, 2:36 am, Andrew Eddie <mambob...@gmail.com> wrote:
> There are no hard and fast rules about how you should do this, just
> find the best groove that works for you. The end result would be to
> create a diff patch that I can drop over the trunk - that would be the
> most convenient if it's possible. I recommend merging down from the
> trunk daily so you don't get too far out of sync but I don't think
> much action is taking place in the files you'll be touching.
> > Do you want to do a quick skype meeting with Fotis and myself, and get a
> > game plan? That might be good. We need to make sure to share our plans in
> > this thread - and also via the wiki.
> >http://docs.joomla.org/Refactoring_Plugins
> > Fotis around? :)
> > On Fri, Nov 27, 2009 at 5:09 PM, Stian Didriksen <st...@ninjatheme.com>
> > wrote:
> >> I'm a little unsure how to proceed here. Do we just continue working
> >> on that branch then have someone do a "all for one, one for all" merge
> >> to trunk or submit a patch?
> >> I'll just commit to the plugin_dirs branch until further notice just
> >> to get some work done :)
> >> On Nov 25, 9:27 pm, Amy Stephen <amystep...@gmail.com> wrote:
> >> > Thanks, Sam, for providing access to Fotis, Stian, and myself to
> >> > Ercan's branch.
The xml installer for frontend modules are finished.
I have submitted the patch to the patch tracker. A short feedback if I
have done this right would be nice. Then I can start with the back end
modules.
Regards, Marco
On 30 Nov., 01:04, Andrew Eddie <mambob...@gmail.com> wrote:
On Mon, Nov 30, 2009 at 7:11 AM, Marco <marco.beie...@googlemail.com> wrote:
> The xml installer for frontend modules are finished.
> I have submitted the patch to the patch tracker. A short feedback if I
> have done this right would be nice. Then I can start with the back end
> modules.
> Regards, Marco
> On 30 Nov., 01:04, Andrew Eddie <mambob...@gmail.com> wrote:
> > Thanks Marco.
> > 2009/11/28 Marco <marco.beie...@googlemail.com>:
> > > Hello,
> > > I'm going to make the modules installable, starting with the front end
> > > modules.
> > > Regards, Marco
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To post to this group, send email to joomla-dev-cms@googlegroups.com
> To unsubscribe from this group, send email to
> joomla-dev-cms+unsubscribe@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB > -~----------~----~----~----~------~----~------~--~---
-- Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org
> How's the branch coming? Do we have something ready to merge back down to > trunk? You guys need feedback on anything?
> Cheers, > Louis
> On Mon, Nov 30, 2009 at 7:11 AM, Marco <marco.beie...@googlemail.com>wrote:
>> The xml installer for frontend modules are finished. >> I have submitted the patch to the patch tracker. A short feedback if I >> have done this right would be nice. Then I can start with the back end >> modules.
>> Regards, Marco
>> On 30 Nov., 01:04, Andrew Eddie <mambob...@gmail.com> wrote: >> > Thanks Marco.
>> > 2009/11/28 Marco <marco.beie...@googlemail.com>:
>> > > Hello,
>> > > I'm going to make the modules installable, starting with the front end >> > > modules.
>> > > Regards, Marco >> --~--~---------~--~----~------------~-------~--~----~ >> You received this message because you are subscribed to the Google Groups >> "Joomla! CMS Development" group. >> To post to this group, send email to joomla-dev-cms@googlegroups.com >> To unsubscribe from this group, send email to >> joomla-dev-cms+unsubscribe@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com> >> For more options, visit this group at >> http://groups.google.com/group/joomla-dev-cms?hl=en-GB >> -~----------~----~----~----~------~----~------~--~---
> -- > Development Coordinator > Joomla! ... because open source matters. > http://www.joomla.org
-- Development Coordinator Joomla! ... because open source matters. http://www.joomla.org
> On Fri, Dec 11, 2009 at 5:25 PM, Louis Landry <louis.lan...@joomla.org> wrote:
>> Amy, Fotis, and Stian, >> How's the branch coming? Do we have something ready to merge back down to trunk? You guys need feedback on anything? >> Cheers, >> Louis
>> On Mon, Nov 30, 2009 at 7:11 AM, Marco <marco.beie...@googlemail.com> wrote:
>>> The xml installer for frontend modules are finished. >>> I have submitted the patch to the patch tracker. A short feedback if I >>> have done this right would be nice. Then I can start with the back end >>> modules.
>>> Regards, Marco
>>> On 30 Nov., 01:04, Andrew Eddie <mambob...@gmail.com> wrote: >>> > Thanks Marco.
>>> > 2009/11/28 Marco <marco.beie...@googlemail.com>:
>>> > > Hello,
>>> > > I'm going to make the modules installable, starting with the front end >>> > > modules.
>>> > > Regards, Marco >>> --~--~---------~--~----~------------~-------~--~----~ >>> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group. >>> To post to this group, send email to joomla-dev-cms@googlegroups.com >>> To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com >>> For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB >>> -~----------~----~----~----~------~----~------~--~---
>> -- >> Development Coordinator >> Joomla! ... because open source matters. >> http://www.joomla.org
> -- > Development Coordinator > Joomla! ... because open source matters. > http://www.joomla.org
> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group. > To post to this group, send an email to joomla-dev-cms@googlegroups.com. > To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> 2009/12/22 Louis Landry <louis.lan...@joomla.org>
> > Nothing? > > - Louis
> > On Fri, Dec 11, 2009 at 5:25 PM, Louis Landry <louis.lan...@joomla.org> wrote:
> >> Amy, Fotis, and Stian, > >> How's the branch coming? Do we have something ready to merge back down to trunk? You guys need feedback on anything? > >> Cheers, > >> Louis
> >> On Mon, Nov 30, 2009 at 7:11 AM, Marco <marco.beie...@googlemail.com> wrote:
> >>> The xml installer for frontend modules are finished. > >>> I have submitted the patch to the patch tracker. A short feedback if I > >>> have done this right would be nice. Then I can start with the back end > >>> modules.
> >>> Regards, Marco
> >>> On 30 Nov., 01:04, Andrew Eddie <mambob...@gmail.com> wrote: > >>> > Thanks Marco.
> >>> > 2009/11/28 Marco <marco.beie...@googlemail.com>:
> >>> > > Hello,
> >>> > > I'm going to make the modules installable, starting with the front end > >>> > > modules.
> >>> > > Regards, Marco > >>> --~--~---------~--~----~------------~-------~--~----~ > >>> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group. > >>> To post to this group, send email to joomla-dev-cms@googlegroups.com > >>> To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com > >>> For more options, visit this group athttp://groups.google.com/group/joomla-dev-cms?hl=en-GB > >>> -~----------~----~----~----~------~----~------~--~---
> >> -- > >> Development Coordinator > >> Joomla! ... because open source matters. > >>http://www.joomla.org
> > -- > > Development Coordinator > > Joomla! ... because open source matters. > >http://www.joomla.org
> > --
> > You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group. > > To post to this group, send an email to joomla-dev-cms@googlegroups.com. > > To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com. > > For more options, visit this group athttp://groups.google.com/group/joomla-dev-cms?hl=en-GB.
Hi Marco. We have a branch where we are working on front-end components. Perhaps it would make sense for you to work with us on this branch? Let me know and we can coordinate this. Thanks. Mark
On Wed, Jan 20, 2010 at 12:06 AM, Marco <marco.beie...@googlemail.com> wrote: > Hey, I'm going to do the xml for frontend components next, if nobody > working at it... (?) > Regards, Marco
> On 19 Jan., 06:36, Andrew Eddie <mambob...@gmail.com> wrote: >> Just following up on this one. JM has finished the plugin folder >> conversion (thanks) and I've given the XML file task to other people.
>> 2009/12/22 Louis Landry <louis.lan...@joomla.org>
>> > Nothing? >> > - Louis
>> > On Fri, Dec 11, 2009 at 5:25 PM, Louis Landry <louis.lan...@joomla.org> wrote:
>> >> Amy, Fotis, and Stian, >> >> How's the branch coming? Do we have something ready to merge back down to trunk? You guys need feedback on anything? >> >> Cheers, >> >> Louis
>> >> On Mon, Nov 30, 2009 at 7:11 AM, Marco <marco.beie...@googlemail.com> wrote:
>> >>> The xml installer for frontend modules are finished. >> >>> I have submitted the patch to the patch tracker. A short feedback if I >> >>> have done this right would be nice. Then I can start with the back end >> >>> modules.
>> >>> Regards, Marco
>> >>> On 30 Nov., 01:04, Andrew Eddie <mambob...@gmail.com> wrote: >> >>> > Thanks Marco.
>> >>> > 2009/11/28 Marco <marco.beie...@googlemail.com>:
>> >>> > > Hello,
>> >>> > > I'm going to make the modules installable, starting with the front end >> >>> > > modules.
>> >>> > > Regards, Marco >> >>> --~--~---------~--~----~------------~-------~--~----~ >> >>> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group. >> >>> To post to this group, send email to joomla-dev-cms@googlegroups.com >> >>> To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com >> >>> For more options, visit this group athttp://groups.google.com/group/joomla-dev-cms?hl=en-GB >> >>> -~----------~----~----~----~------~----~------~--~---
>> >> -- >> >> Development Coordinator >> >> Joomla! ... because open source matters. >> >>http://www.joomla.org
>> > -- >> > Development Coordinator >> > Joomla! ... because open source matters. >> >http://www.joomla.org
>> > --
>> > You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group. >> > To post to this group, send an email to joomla-dev-cms@googlegroups.com. >> > To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com. >> > For more options, visit this group athttp://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> -- > You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group. > To post to this group, send an email to joomla-dev-cms@googlegroups.com. > To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
