Decoupling com_weblinks

[Andrew Eddie]

I think the vision for this in the new Joomla 3.4 (http://developer.joomla.org/news/583-announcing-joomla-cms-3-4.html) is a rather exciting prospect. It's also rather daunting at the same time because there are a lot of moving pieces we take for granted when an extension is included in the core.

I'm interested in having a go at this one with a view that is becomes a bit of a template for future decoupling, and also a guide to developers that want to build extensions suites (we always seem to pick on com_weblinks to try new things). Is there was anyone else interested in working on this, er, feature?

Regards,

Andrew Eddie

[Bob Bloom]

Hello Andrew,

I am interested in helping with this exercise. 

There is a GitHub repo that I was following, but cannot seem to find now. It is a project to bust up the Joomla CMS into separate repos. The issues that were raised were quite broad, including what folder structure to follow, would there standard Phing files in the repo, etc. 

Decoupling com_weblinks in the live Joomla seems like a way to ripen these issues beyond the discussion phase. It might be a consideration to pursue this live decoupling exercise in a Github repo, while "coupling" it (hehe) with that existing GitHub repo that I can't seem to find, as the discussions there were quite detailed.

I see there's https://github.com/joomla-extensions/weblinks. 

-Bob

[Andrew Eddie]

On 8 April 2014 14:37, Bob Bloom <> wrote:
> I am interested in helping with this exercise.

Awesome!

> I see there's https://github.com/joomla-extensions/weblinks.

Yep, that's the one we'll be using.

Regards,
Andrew Eddie

[ste...@gmail.com]

For Joomla 1.5 there was a extension called enhanced weblinks. It took the joomla weblinks and extended them to add some much needed functionality. I don't think it is available any longer in JED, but it might be of interest to see how the author built his extension. I think I still have a copy if anyone would like to see,

Steve 

[Andrew Eddie]

On 8 April 2014 21:02, <> wrote:
> I think I still have a copy if
> anyone would like to see,

Interesting. There is no reason why we can't extend com_weblinks to be
actually useful, but we'd need to be careful about how we use other
people's work. Ideas are ok but if there's code we can port, we'd need
to get the original author to sign the JCA if they haven't already.
But with that in mind, sounds like a plan!

Regards,
Andrew Eddie

[Andrew Eddie]

First draft-nothing-set-in-stone cut off the block (modelled on work
Michael Babker has done previously):

https://github.com/joomla-extensions/weblinks

You will need Phing to be able to run the build script (see
https://github.com/joomla-extensions/weblinks/blob/master/CONTRIBUTING.md#release-procedure).

and some discussion starters:

https://github.com/joomla-extensions/weblinks/issues

Enjoy!

Regards,
Andrew Eddie

[Andrew Eddie]

PLT, I think we need some scope determination on the Weblinks project:

1. Is changing the mechanism for end-user and developer documentation
and help screens within the scope of decoupling?
2. Is changing the rules for documentation submission, for example
"all docs complete prior to code merge", within the scope of the
decoupling?
3. Is moving language files from core language packs to extension
language packs within scope?
4. Is hosting builds as release files within the Github system within scope?
5. Are there any special requirements for how the folder structure of
the repository is to be set out?

I don't think we can move forward until we get a definitive yay or nay
on those items. My assumption was we'd treat the decoupled extension
as closely as possible to how a 3PD would treat their own extension
with the view that we experience some of the problems they face and
try to give them a bit of pain relief. My vision in that regard I
suspect may be too ambitious.

Thanks in advance for your guidance on these matters.

Regards,
Andrew Eddie

[Michael Babker]

All answers are my own opinion and do not reflect an official response from the PLT.

On Thu, Apr 10, 2014 at 2:58 AM, Andrew Eddie <mamb...@gmail.com> wrote:

1. Is changing the mechanism for end-user and developer documentation
and help screens within the scope of decoupling?

Initially, I would say no.  I'd personally rather focus on dealing with getting the code out of the main distro and working out the logistics of maintaining it as a separate extension before moving on to areas such as documentation.

2. Is changing the rules for documentation submission, for example
"all docs complete prior to code merge", within the scope of the
decoupling?

I'd be OK with this moving forward.  For the decoupling piece specifically, as we move forward with repo structure, working out build and release processes, and whatever else, those should be documented as it happens.  Afterwards, I think we could fall into a Framework like workflow where docs are required for changes (even if it's a bug fix, just explaining the bug).

3. Is moving language files from core language packs to extension
language packs within scope?

I think we should be working towards how to get the language files out of the main distro with this, but this might be the one piece of the decoupling process where I might compromise temporarily.

4. Is hosting builds as release files within the Github system within scope?

If you're suggesting using GitHub's releases system to publish packages, then yes.  If you're not, then please clarify what you're asking.

5. Are there any special requirements for how the folder structure of
the repository is to be set out?

What you have now is fine for me.  I know others have strong opinions, but I don't think there's a right answer for this one.  I would suggest though that we make our behavior consistent moving forward.  com_patchtester matches the installed structure right now and the weblinks repo is organized for packaging versus development; moving forward those two repos (and others as we get more extensions in a decoupled or "official" state) should be structured similarly for consistency.

I don't think we can move forward until we get a definitive yay or nay
on those items. My assumption was we'd treat the decoupled extension
as closely as possible to how a 3PD would treat their own extension
with the view that we experience some of the problems they face and
try to give them a bit of pain relief. My vision in that regard I
suspect may be too ambitious.

I don't think we're going to get a definitive answer one way or another on these things at first.  Taking a true 3PD approach should be the goal though.

[brian teeman]

the one thing thats not really been discussed yet is the process for uninstalling weblinks

Currently to uninstall all the parts of weblinks that are being discussed as being decoupled you need to uninstall

1. Component

2. Module

3. Search plugin

4. Smart Search plugin

5. language files

Ignoring the language files which are coupled to the core language files and probably impossible to uninstall would it be possible to ADD a weblinks package xml file in the next release of joomla. This would hopefully mean that ALL the constituent parts of weblinks could be uninstalled in one process

[Michael Babker]

Certainly feasible

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--
- Michael

Please pardon any errors, this message was sent from my iPhone.

[Andrew Eddie]

Thanks Michael. It would be helpful if you can confirm that the
majority of the PLT is on the same page. What I'm reading is there
everything can be up for negotiation but not everything will be
possible in 3.4?

Yes, I meant Github releases. I felt that was a no-brainer but given
the pushback on areas that I thought were obvious, I needed to make
sure.

Brian, regarding uninstallation, if you upgrade to 3.4 we will need to
confirm that you can uninstall Weblinks completely (subject to
agreeing on a roadmap for translations). Do you see a need to have
this fixed before 3.4?

Regards,
Andrew Eddie

> --
> You received this message because you are subscribed to a topic in the

> Google Groups "Joomla! CMS Development" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/joomla-dev-cms/_QeFxkf8W08/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[brian teeman]

On Thursday, 10 April 2014 23:04:35 UTC+1, Andrew Eddie wrote:

Thanks Michael. It would be helpful if you can confirm that the
majority of the PLT is on the same page. What I'm reading is there
everything can be up for negotiation but not everything will be
possible in 3.4?

Yes, I meant Github releases. I felt that was a no-brainer but given
the pushback on areas that I thought were obvious, I needed to make
sure.

Brian, regarding uninstallation, if you upgrade to 3.4 we will need to
confirm that you can uninstall Weblinks completely (subject to
agreeing on a roadmap for translations). Do you see a need to have
this fixed before 3.4?

Sooner is always better than later - and its only a single file to add iirc

[Michael Babker]

By the time 3.4 ships, the package manifest will need to be added and an extension record added to the extensions table.  I'd personally rather not do this until we confirm weblinks will be stripped from the package, but the patch can be prepared at anytime once we open the 3.4-dev branch to validate the added data and uninstall capability.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

[Andrew Eddie]

On 11 April 2014 08:39, brian teeman <> wrote:
> Sooner is always better than later - and its only a single file to add iirc

Sorry, I didn't make myself clear. Why do you think this is important
prior to 3.4?

Regards,
Andrew Eddie

[Andrew Eddie]

There's been no community input for nearly a month so I'm proposing
the current state of the repository is ready for official review:

https://github.com/joomla-extensions/weblinks

If there is anyone interested in taking this small project over, let
me know and I'll grant you access to the repo.

Regards,
Andrew Eddie

[George Wilson]

So do we have a plan of action for translators. I'm not sure the issue we opened really reached a conclusion when it was shut.

Also how is installing sample data going to work?

Kind Regards,

George

[Andrew Eddie]

On 11 May 2014 01:41, George Wilson <> wrote:
> So do we have a plan of action for translators. I'm not sure the issue we
> opened really reached a conclusion when it was shut.

As far as the current code base is concerned there are two possibilities:

1. Send in a pull request to add languages directly to the extension package.
2. Make your own language pack using whatever method you care to use.

> Also how is installing sample data going to work?

Personally, I don't think that's a high priority and it's something
that can be solved at a later date.

Regards,
Andrew Eddie