Roadmap to remove search

[brian teeman]

I see that the roadmap has been updated and it says that both the core search components will be decoupled and removed from new installs. 

I get why Smart Search (com_finder) will be decoupled as it has numerous issues but it makes no sense to me at all that we will be shipping a CMS without any core search functionality.

[brian teeman]

The roadmap also states

" One determining factor was the availability of better alternatives located through other third-party sources. Not all of the above extensions may have well-known alternatives but most do."

I just spent some time on the JED and there is only one alternative search extension which has poor reviews and more limited functionality than com_search

[Niels Braczek]

The problem with com_search is, that it hinders adoption of better
solutions (eg., ElasticSearch).

Search is important, so it makes sense to signal the open-ness for
better solutions by moving com_search to core extensions.
A switch at installation time could minimize the impact in userland.

Regards,
Niels

--
| New Stars on the Horizon: GreenCape · nibralab · laJoom |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[brian teeman]

ElasticSearch are you being serious? Have you ever seen that running on the type of typical shared hosting most Joomla sites are on.

Even if it did run - removing a core feature to encourage someone to create something else is coming from cloud cuckoo land.

Lets remove all components and suggest that is to encourage people to develop something else completely

[Jon Neubauer]

I agree that we need to keep some sort of search. Search, even a basic, general purpose search, is an integral feature for any major Content Management System.

Unlike components such as weblinks or newsfeeds - which are just highly specific types of content - search, even in a basic form, is expected for a system that manages content.

I know the roadmap doesn't currently state that we're totally abandoning those extensions - but removing all search capabilities from the core installation only serves to shoot ourselves in the foot, and will lose new users who will try Joomla and notice a major important feature missing almost right away.

[Karlos Rikáryo]

Always liked the simple search as the default Joomla !, already advanced research always has a kind of villain when sent attach the content, it might be wisdom on our part to keep the simple search and put the advanced search uninstalled by default, and the search simple could be added a higher character limit in the search, since today there are few characters and many complaints has it!

hugs

Em Mon, 20 Jul 2015 15:08:47 -0300, Jon Neubauer <jon.ne...@community.joomla.org> escreveu:

I agree that we need to keep some sort of search. Search, even a basic, general purpose search, is an integral feature for any major Content Management System. Unlike components such as weblinks or newsfeeds - which are just highly specific types of content - search, even in a basic form, is expected for a system that manages content. I know the roadmap doesn't currently state that we're totally abandoning those extensions - but removing all search capabilities from the core installation only serves to shoot ourselves in the foot, and will lose new users who will try Joomla and notice a major important feature missing almost right away.

--

Karlos Rikáryo
CEO - Herói Nerd - Inventtive
(88)9646.2781
www.heroinerd.com.br | www.inventtive.com.br

Economize papel, preserve as árvores/Save paper, save a tree. Você realmente necessita imprimir esta mensagem ?/Do you really need to print this mail?

[Niels Braczek]

Am 20.07.2015 um 19:00 schrieb brian teeman:

> ElasticSearch are you being serious? Have you ever seen that running on the
> type of typical shared hosting most Joomla sites are on.

Well, what I see is a lot of sites without search at all. Personally, I
agree to the removal *only, if* it is not more than one click away
(during installation).

> Lets remove all components and suggest that is to encourage people to
> develop something else completely

Maybe that's not a too bad idea. It has been out there several times
already. It was just called 'distributions'.

In terms of roadmap (how I understand it - it is my personal view),
"removing from core into a core extension" means just one thing:
decouple it, so it can be replaced with other or better solutions. I
expect core extensions to be selectable during install (when we have
appropriate interfaces in place, a choice between core and 3PD
alternatives implementing the same interface). Core extensions could
even be pre-selected, so doing nothing to the selection screen would
yield in installing the current feature set. The roadmap tells *nothing*
about those things.

So, removing search is not bad per se. It depends on, however, how it is
handled afterwards.

[brian teeman]

On Monday, 20 July 2015 19:28:32 UTC+1, Niels Braczek wrote:

Am 20.07.2015 um 19:00 schrieb brian teeman:

> ElasticSearch are you being serious? Have you ever seen that running on the
> type of typical shared hosting most Joomla sites are on.

Well, what I see is a lot of sites without search at all. Personally, I
agree to the removal *only, if* it is not more than one click away
(during installation).

and it is not

 

> Lets remove all components and suggest that is to encourage people to
> develop something else completely

In terms of roadmap (how I understand it - it is my personal view),
"removing from core into a core extension" means just one thing:
decouple it, so it can be replaced with other or better solutions. I
expect core extensions to be selectable during install (when we have
appropriate interfaces in place, a choice between core and 3PD
alternatives implementing the same interface). Core extensions could
even be pre-selected, so doing nothing to the selection screen would
yield in installing the current feature set. The roadmap tells *nothing*
about those things.

None of that is in the roadmap unfortunately and there is no one writing code to support that functionality

 

[Michael Babker]

Like I pointed out on Twitter last night, I've got proof of concept code from over 2 years ago to add that extra step to the installer (and inherently a separate tab in the Extension Manager; this was before Install from Web); it's all based on the same logic used for the language listing in the install app.  Anyone's free to borrow the logic and try to craft something for our current structure.

I'll not rehash everything I said here, but long and short, we honestly need to be focusing more effort on improving Joomla's search implementation(s) and baking it into the heart of the API instead of spending time discussing what extension(s) are "suitable" for being removed from the main distro.  And apparently other logistical issues that call to question whether decoupling can even happen (depending on what you think the behaviors should be).

 

--
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.

[Joerg]

Agree with Brian in this case. I'm a happy com_search user. Even use a plugin which enables it to search for products in my shop. At present I wouldn't trade it for any of the available external search plugins.
Might not be perfect, but it's a good compromise which should be supplied with every Joomla installation. If it's decoupled, then it would probably be a good idea to adjust the Joomla installer, which could for example display a list of decoupled extensions in which the 'normally' used ones are preselected. I think something like Elasticsearch doesn't make any sense in the shared hosting environment.

[Michael Babker]

Here's the thing though.  We have zero use data, so there is no way to have a list of what is "normally" used, or even a way to make an informed decision about what aspects of the CMS are used regularly enough to say "there's no way we can strip this out"; all of us are guessing based on our experiences and use cases.  If I were making the decisions based on my own site deployments, search would fall into the not-pre-selected list because most sites for me don't use search or adding it was an after thought that wasn't part of the requirements.  Others in this thread would have it in the pre-selected list because they do use it in most cases.

If we have a "pre-selected" list, IMO it can only be an all or nothing thing as we lack the data to make good decisions otherwise.  Or we finally get some user data and make data driven decisions, but even if we started today we're too far out from being able to make informed decisions on that data.

On Mon, Jul 20, 2015 at 2:56 PM, Joerg <ma...@seebestattung-hawaii.de> wrote:

Agree with Brian in this case. I'm a happy com_search user. Even use a plugin which enables it to search for products in my shop. At present I wouldn't trade it for any of the available external search plugins.
Might not be perfect, but it's a good compromise which should be supplied with every Joomla installation. If it's decoupled, then it would probably be a good idea to adjust the Joomla installer, which could for example display a list of decoupled extensions in which the 'normally' used ones are preselected. I think something like Elasticsearch doesn't make any sense in the shared hosting environment.

--

[Vic Drover]

To follow that through to it's conclusion, if you cannot make a data-driven solution, how did someone reach come to the decision to remove com_search in the first place?

Cheers,

Victor Drover
Founder and CEO, Anything Digital
Co-founder, Watchful.li & jInbound.com
262-923-8200 ext. 0
Facebook: AnythingDigital | watchfulli | JInbound
Twitter: @VicDrover | @AnythingDig | @watchfulli | @JoomlaInbound

[Michael Babker]

A decision to modularize the CMS and decouple as much of the platform as practical/possible.  com_search isn't a requirement to make the CMS actually work out-of-the-box, so it can be argued that it could be moved out of the main distribution from that aspect (in reality aside from a few admin management extensions, everything in the CMS should be decouple-able but I get the feeling we've got some funky dependencies somewhere that make this an unrealistic goal).

[Vic Drover]

I agree wholeheartedly with the move to modularize and decouple, but as Brian pointed out, a basic search and contact form are pretty import for most websites. We could modularize com_categories I suppose and only offer it to folks who needed the feature, but we are all pretty confident that it's important. 

I'd make the same argument with com_search. 

In short, modularize everything, but keep com_search in the core installer, perhaps with the ability to uninstall if desired.

Cheers,

Victor Drover
Founder and CEO, Anything Digital
Co-founder, Watchful.li & jInbound.com
262-923-8200 ext. 0
Facebook: AnythingDigital | watchfulli | JInbound
Twitter: @VicDrover | @AnythingDig | @watchfulli | @JoomlaInbound

[Roberto Segura]

Search is one of those things were a standard to use between all the extensions makes sense (like multilanguage, acl, etc.).

So a requirement IMO.

[brian teeman]

Com_categories is one of those that is too tightly coupled everywhere it couldn't be removed. Almost all components depend on it

[Vic Drover]

Of course it's a requirement. So is searchm just for a different reason.

[Michael Babker]

Speaking from a pure technical aspect right now, everyone who thinks I need to think more like an end-user can ignore the next couple of paragraphs ;-)

The CMS is an application shipped in a pre-built configuration with ~130 extensions (count based on rows in the extensions table).  An issue that we have is that we do not treat a lot of these items as extensions, we treat them as the core of the CMS.  From a user perspective and the features that are offered, this is a perfectly valid assumption, but as long as I've been around Joomla my impression has always been that we should not be building things around components.  So our current category and tags APIs, for example, can basically only work with the core category and tag components; it's rather impractical to be able to build an alternative tag or category manager that extensions would be able to plug into the way things do now with those two components.  Speaking purely as a coder, this is not acceptable.  And because of how everything is coded, it means that com_categories and com_tags are not modular extensions; their removal would completely destroy a site.  If this is the case, their APIs should be extracted into the library layer (the stuff in the libraries folder) and the component redesigned to be a visual representation of that API.  That type of work is probably a 4.0 item with no chance of being done "right" or even "good" in 3.x.

com_search is one of those things that is a full extension implementation.  In fact, neither of our search platforms have a real library level API aside from a single method to log search terms (https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/search/helper.php).  At a technical level, its featureset can be completely removed from the CMS and wouldn't break a thing; an end user could install any chosen search platform that is written for Joomla and be able to implement search.

So coming back around to this as an end user.  They aren't going to see any of these types of technical issues.  They just see "well Joomla does X Y and Z out of the box, but lacks W which WordPress does, I'm picking them".  And that's the problem of trying to please masters in a lot of different environments, the end user doesn't care how bad the code functions as long as it works and developers as they mature hate being around bad code structures.

Is search functionality a user requirement?  In a majority of cases, probably (can't answer in a definitive way; for me it isn't but for others it is and we have no data).  Is search a technical requirement to make a CMS function?  No.  Which group should win here?  If you say the user requirements are stronger, what's to say we shouldn't work on making the platform decouple-able to allow folks who don't use the core features (either not at all or use a different solution for the same function) uninstallable?  If you say the technical requirements are stronger, how do we improve the user side of things in the overall balancing act?

One solution that came up was integrating stuff into the installer and the extension manager.  Please, someone, take my code concepts from 2 years ago and use it (no, I don't have the time nor the desire at the moment to update it and fight for it to be merged, my last architectural concern was pretty much written off anyway as a "m'eh").  I'm begging you.  Hiding the core features in a JED category which is not promoted ANYWHERE (.org properties, in the CMS, anything) just makes it sound as bad as people are making it out to be.

So looping back around to the technical side of things.  There is a known weakness in both our search platforms.  There is a known inconsistency in their APIs.  And it is pretty well known that no search functionality is baked into the core (I'm talking the libraries folder here, not the ZIP'ed up distro) API.  To be blunt, we're wasting time debating what extension(s) should or shouldn't be uninstallable right now.  There are larger architectural issues that need to be on a larger group's radar than the J4WG.  This is one of them.  Decoupling needs to be on the radar, but if we're going to argue over what extensions are "uninstallable" and use it as a distraction from working toward (what I think is) a good goal of proper separation of our architectural features and implementations, then we need to just nip it in the bud now and move on to something else.

[Wilco Jansen]

Search is important, and should be part of the CMS framework (I am referring to application frameworks here). Current search options are kind of limiting, agree from that perspective. Looking at the modern solutions (foss and commercial) a good search is standard nowadays (having a bad search will be a dissatisfier). Has a unified content model been considered? One that you can extend with any kind of extension that the end-user needs? (ranging from simple to more complex solutions, search, tagging, indexing etc.)

[Webdongle Elgnodbew]

imho all so called 'de-coupled' components should be installed by default with the option for the user to deselect.

To remove components from the default install is backward but to allow users to deselect components is an enhancement.

[Michael Babker]

So there's a little kink with that option right now.  Our update platform has no way of knowing what extensions which compose the full CMS are installed and which ones aren't.  So while today you can uninstall banners, search (both of them), and other stuff, all that code eventually ends back up in your site's filesystem running updates.  That's a much deeper issue that quite frankly needs a lot of time and thought too.  And no the decoupling effort shouldn't be an excuse to ignore that, just in case someone gets the wild idea that we're avoiding one issue by "fixing" another.

Part of the logic with decoupling is that you have smaller pieces of code to deal with; you can scrutinize things more closely, updates are typically smaller in size and more focused on certain areas, and other "technical" things that most end users would probably just shrug and be like whatever over.  So instead of having a full release just to fix an issue in the update component, you can just update the update component and move on with life (bad example since that is something that shouldn't be decouple-able, but there has actually been twice where this has been needed and we have support for doing just that built into the CMS now).

--

[Troy]

I totally agree.  Not having a GOOD search engine is ridiculous.  To be honest I don't understand why we don't have a high quality search engine like RokAjaxSearch as a core feature.

Bear

On 7/20/2015 10:35, brian teeman wrote:

I see that the roadmap has been updated and it says that both the core search components will be decoupled and removed from new installs. 

I get why Smart Search (com_finder) will be decoupled as it has numerous issues but it makes no sense to me at all that we will be shipping a CMS without any core search functionality.

--
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.

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6081 / Virus Database: 4392/10273 - Release Date: 07/20/15

[Troy]

sounds reasonable

Bear

No virus found in this message.

[Troy]

EXACTLY

Bear

--

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.

No virus found in this message.
Checked by AVG - www.avg.com

Version: 2015.0.6081 / Virus Database: 4392/10275 - Release Date: 07/20/15

[Michael Babker]

You do realize that module is only a wrapper around Joomla's core search component to improve the UX on the search box and give the possibility of connecting to Google, right?  It isn't an actual search platform as either core search component are.

--
- Michael

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

[Troy]

ok, what I love about rok is the ajax, and seems to find a bit more, but yes, it doesn't find alot of words that I know are in articles.

Bear

[FR]

+1 for decoupling com_search too

+1 for giving users the option to opt-in or opt-out for decoupled extensions during CMS installation

[Joerg]

On Monday, July 20, 2015 at 10:54:04 PM UTC+2, Michael Babker wrote:

There is a known weakness in both our search platforms...

I'm not a developer, so I'm unable to evaluate possible alternatives. Just googled a little bit...
Would something like this qualify as a replacement for the current search platforms? http://www.tipue.com/search/

[brian teeman]

Its not about there being alternatives available or if the current options are good or bad. 

Its about the roadmap stating that Joomla will NOT include any search functionality at all in a new install 

[Niels Braczek]

Am 21.07.2015 um 12:19 schrieb Joerg:

> Would something like this qualify as a replacement for the current search
> platforms? http://www.tipue.com/search/

No, since it runs in the browser. The search happens on the server's
database.

[Lapoux Sébastien]

Hi,

Decoupling com_search and com_finder of the CMS is not related to the question "Do we need search feature in the native Joomla installation?".

Of course and I think like a majority:

• +1 about decoupling com_search and com_finder

The question "Do we need search feature in the native Joomla installation?" is not related to technical purpose but more about marketing/communication/user perception to use or not Joomla.

There is no discussion that a lot of people is considering this feature has a basic feature of a CMS. And if you're not agree tell us which popular CMS has no native search feature?

So if we're agree that native search feature is required what is the best way to provide this:

• included com_search by default (or com_finder?)
• allow the installation of com_search and/or com_finder during the Joomla installation process such as proposed by FR
• other?

Thanks.

[brian teeman]

Sébastien

Can you explain please what you mean by decoupling then. Both com_search and com-finder can be uninstalled right now without breaking anything so there is no code to decouple - unlike com-categories which is integral to the codebase

[Lapoux Sébastien]

Thanks Brian!

So in regards of your feedback com_search and com_finder are already decoupling (no dependency in Joomla core). I was not sure about that. Sorry! (I read your answer here http://forum.joomla.org/viewtopic.php?f=706&t=880796&view=next). For me "decoupling" is about "no dependency in Joomla core" and not about including natively the component or not. Sorry for the misunderstanding and the noise here.

So like I said totally agree with you and the fact that Joomla need natively search feature.

[brian teeman]

No problem

[Webdongle Elgnodbew]

"So there's a little kink with that option right now.  Our update platform has no way of knowing what extensions which compose the full CMS are installed and which ones aren't.  So while today you can uninstall banners, search (both of them), and other stuff, all that code eventually ends back up in your site's filesystem running updates. "

On Monday, 20 July 2015 22:54:36 UTC+1, Michael Babker wrote:

So there's a little kink with that option right now.  Our update platform has no way of knowing what extensions which compose the full CMS are installed and which ones aren't.  So while today you can uninstall banners, search (both of them), and other stuff, all that code eventually ends back up in your site's filesystem running updates.  That's a much deeper issue that quite frankly needs a lot of time and thought too. ...

So how difficult would it be to add an 'if exists' statement before writing files or database tables of the Components (users can deselect) are updated ?

 

[Michael Babker]

Actually, very difficult as far as the filesystem goes (the database stuff gets a little trickier; we tried a stored procedure to deal with weblinks database changes conditionally between 2.5 and 3.4 and ended up having to rewrite that aspect of the upgrade in our PHP API versus SQL statements, but it is theoretically possible to deal with somewhere).  The CMS is updated as a file extension type, so it follows the same rules as any Joomla extension (well, mostly, we sadly have one "extension" specific hack already at https://github.com/joomla/joomla-cms/blob/3.4.3/libraries/cms/installer/adapter/file.php#L199).  Without a fully customized extension adapter or just rewriting the update system to not use the extension update platform, our hands are kind of tied on that.

[Bakual]

Michael already explained that a bit further down.

If you uninstall search and/or finder, changes are high the files will come back on the next Joomla update. That is because it is tied into the system.

Decoupling them would allow to truly uninstall the unneeded search, and almost all sites will have at least one of them not needed.

Decoupling also allows to update the extension without having to release and update the full Joomla suite.

The question if we want to ship Joomla with a search or not is indeed valid, but not necessary tied to the question of decoupling them.

The idea of the decoupling was to be able to build distros. And when you think about that it makes perfectly sense to have a basis distro containing a search and some other decoupled extensions (eg com_contact for the contact form).

So far we only have weblinks decoupled, and it didn't made sense to have an extra step in the installer to install it directly or offering a distro which has it included. But if we have more extensions decoupled that would make more sense of course. Michael already wrote a proof of concept code to add that step to the installer.

The most interesting question for me would be how we want to handle that. Do we want to offer distros containing a sample set of extensions? Do we want that extra step in the installer (similar to language installs)? Should that step allow to install all extensions from JED or only the core supported ones? Better ideas?

[Troy]

If we're going to turn into a distro based CMS, then there needs to be 3 install methods.
#1 simple ( Ready to go - turn key, all the standard stuff & data )  like we currently have.
#2 advanced ( standard stuff pre-selected but taken to jed to add/remove )
#3 pro ( absolutely nothing installed but the most minimalistic core. ) then they build it like you do a linux build using yum, apt-get which ever.  they can use jed or w/e method we want to have them use, to pick each piece of software they want to use.  The system would automatically inform of dependency's as needed.  This would probably be nothing more then the framework itself as an "app" engine
just like windows , osx & linux, very few are going to want to make the step to #3 ( iinux ) except dev types.  And probably many of those ( designers ) would choose #2 ( osx ) instead of lazy windows #1

Bear

--

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.

No virus found in this message.
Checked by AVG - www.avg.com

Version: 2015.0.6081 / Virus Database: 4392/10284 - Release Date: 07/22/15

[Walt Sorensen]

Correct me if I'm wrong, but...

Isn't com_finder and com_search both extensions that just add search to the front end? 

By default, don't they also need to be assigned to a published module position before they are displayed to site visitors and usable?

We might not have use data for Joomla sites. But I wonder once you get past search engines, email platforms, and social media, in the top 500 listed in alexa rankings; how many sites really have search functions on page for site visitors? 

should be fairly easy to look at a list like that and see what high traffic sites are doing and how valuable integrated vs add-on search is.

We could also ask the question about what kind of sites are being built with Joomla?

Are the majority of sites news/blog sites or product/catalog sites, Or are the sites more on the level of general 10-20 page sites for small businesses, or intranet sites?

Are the majority of sites built with just the core, or are those sites built with a high degree of add on extensions?

We could also consider what the other major CMS platforms are doing to see how we could do this better or different.

With that said, I'm not sure if search functions would be high on my list to consider decoupling from the CMS core. 

[brian teeman]

On Wednesday, 22 July 2015 17:50:17 UTC+1, Walt Sorensen wrote:

Correct me if I'm wrong, but...

Isn't com_finder and com_search both extensions that just add search to the front end? 

By default, don't they also need to be assigned to a published module position before they are displayed to site visitors and usable?

You can also have a menu item for search

[Joerg]

On Wednesday, July 22, 2015 at 2:45:57 PM UTC+2, Bear wrote:

If we're going to turn into a distro based CMS, then there needs to be 3 install methods.

Some time ago a few people in the Joomla sphere thought that this project would be an interesting approach for the Joomla distribution: Mangrove
Unfortunately it looks like the project stalled for some unknown reason, but you can still find it on Github.

[jms]

As I see it, the problem is that the cart has been put before the horse, i.e. decoupling was started without providing a working solution for customized installations.

This includes not only the possibility to choose the desired extensions at install time but also their specific language packs, as well as being presented updates for these extensions (and their lang packs).

I suggest to seriously consider a pause to this decoupling until all this is solved as this is confusing people (at best…) and just giving Joomla a bad reputation.

Thank you for your attention.

JM

[Bakual]

If we pause now, we will have no progress at all. Because nobody will think about the other needed steps.

Personally, I don't really think it's needed to install additional extensions during the installation itself. This could well be a step proposed in the control panel after the CMS is installed. But that's me. I would rather offer two distros -  a barebone one with only a minimal set of extensions and a full one with everything preinstalled. But that as well could be offered after the installation is done. Like a button in the control panel or a postinstall message which says to install this or that set of extensions.

The language packs is just a question how they should be handled. One could easily include the languages together with the extension itself. It has the disadvantage that updates to the languages require a new update to the extension pack.

Currently, we still do them together with the main language pack for the CMS. That would still also be a solution (probably easiest for translators). With that approach we will have to figure out how we can have the source files in the extension repo and make them still easily available to translators. Would be great if they don't have to manually collect them from the various repos / folders. But that is something which can be solved with a script easily.

[David Deutsch]

Due to a number of personal reasons, I had to put mangrove (and a few other things) on hold for a while. It seems likely that I will return to working on it later this year.

If you have any questions that help along this discussion, just let me know and I'll try to answer them.

-David

[Walt Sorensen]

On Thursday, July 23, 2015 at 1:07:19 AM UTC-6, Bakual wrote:

I would rather offer two distros -  a barebone one with only a minimal set of extensions and a full one with everything preinstalled. But that as well could be offered after the installation is done. Like a button in the control panel or a postinstall message which says to install this or that set of extensions.

There is at least a Third Distro needed. At the first JWC during a discussion session that Paul Orwig held, I suggested that we needed a distro specifically for JUGs. The goal of that distro would be to get a new (or existing) JUG up and running with tools for their local community.

[Michael Babker]

I'd say that's more of an internal resource that our JUGs team should be managing.  But it definitely fits the spirit of what we should be able to do with distros.

--

[piotr_cz]

Does it make sense to work on features like this on current 3.x version?

I mean, it may be harder to decouple components from existing architecture then have prepare functionality to add new components in new modular system.

[Bakual]

We have already proven that it is possible to do. The existing structure isn't an issue.

[Sergio Manzi]

3 weeks ago: https://github.com/joomla/joomla-cms/pull/7008#issuecomment-118437571

What has changed in the meanwhile and why, according to latest roadmap, banners are still not considered for decoupling?

[Bakual]

Imho, banners could easily be on the list of core supported extensions as well.

[Sergio Manzi]

Agreed (and I hope it will happen ASAP), but I was mainly referring to the "... PLT decides to not decuple any more extension for now ..." statement. Has that decision been reverted?

[Bakual]

I'd say obviously yes. Otherwise this thread wouldn't have been created as it is based on the updated roadmap :)

[Sergio Manzi]

OK, thanks: I'll then suggest to re-open #7008 and close #7337 instead...

[George Wilson]

OK So to clarify (Thomas wasn't able to attend the PLT meeting in Prague so I think he's slightly out of the loop). In 3.5 we are only aiming to remove com_messages whilst we evaluate the best way to set up distributions and we are establishing the workflow (whilst in the roadmap as a 3.5 thing realistically this is outside the release cycle of the CMS as it's a build process - that was just to give a timeframe).

The bigger issue is that as per the roadmap the installer improvements won't be coming until around 3.7 (unless people get together and contribute these earlier) and therefore we probably won't be decoupling any more extensions until that point. That's why for now we're asking for the banners extensions to be targeted at the CMS repo for now and so Tobias was perfectly correct to close #7008 for now. Banners almost certainly will be decoupled when we get to that stage - but we aren't ready for that yet.

Kind Regards,

George

[Sergio Manzi]

OK, it is pretty clear, now (and consistent with the roadmap).

A couple of considerations:

• I think banners too should be added to the "core supported" extensions in the roadmap
  
  
• IMHO I will prioritize the "Improve the installation experience" item (geee... that's sounds like Microsoft marketing parlance...): if I'm not mistaken we are in a situation where this partial decoupling renders upgrades from Joomla 2.5 problematic and this must be addressed ASAP.
  JM is right: "the cart has been put before the horse"
  
  
• In the long term (and back on topic) I'm too pro-decoupling of the search functionality, if this is feasible at all. But as we are talking about Q3 2016... many things could happen in the meanwhile!

[Sergio Manzi]

oh... and, IMHO, Tags too should go and find a new home as a core supported extensions!

Unsure about Redirects...

Happy to see that Newsfeeds is on its way out: I couldn't care less, personally, and it has always created me issues.

[George Wilson]

• I think banners too should be added to the "core supported" extensions in the roadmap
  

I agree - although I think it actually has a much higher use case than you'd think (from my experience in Prague) 

• IMHO I will prioritize the "Improve the installation experience" item (geee... that's sounds like Microsoft marketing parlance...): if I'm not mistaken we are in a situation where this partial decoupling renders upgrades from Joomla 2.5 problematic and this must be addressed ASAP.
  JM is right: "the cart has been put before the horse"
  

There is a reason for it being there - the Webservices/Hypermedia API targeted for 3.6 is going to be super important for the Joomla 4 working group to help them build the simple upgrades for people. And that's going to take a lot of effort for the release

Furthermore it's likely the Joomla 4 UX working group (still being setup - see http://community.joomla.org/blogs/community/1870-call-for-ux-team-volunteers.html) will likely be working on an improved installer experience anyhow - in which case it makes sense to combine efforts there at a point when they are set up and ready. At the end of the day the note above that table says that "Please remember all dates are tentative and proposed focus for each release subject to modification" and that is definitely the case - if the code for the installer is ready before then - then we will push it into an earlier release.

FWIW the upgrade of weblinks from 2.5 was just a bug in the SQL upgrade script and has been fixed with the release of Weblink 3.4.1 earlier this week.

 

• In the long term (and back on topic) I'm too pro-decoupling of the search functionality, if this is feasible at all. But as we are talking about Q3 2016... many things could happen in the meanwhile!

Pretty much :P

Kind Regards,

George 

[Michael Babker]

On Sat, Jul 25, 2015 at 10:57 AM, Sergio Manzi <s...@smz.it> wrote:

oh... and, IMHO, Tags too should go and find a new home as a core supported extensions!

HA!  HAHAHA!

In all seriousness, it can't.  The way the tags API is written is very similar to that of com_categories.  Good luck pulling either of those components out of Joomla and not watching your site crash in a blaze of glory.

(though I wish it were possible...)

[Sergio Manzi]

Foods for thoughts for 4.0, methink... ;-)

[Bakual]

There exists no issue when updating from 2.5. THere was an issue because the weblinks update manifest was (intentional) broken. But that has been fixed now and there is a release 3 4 1. So all is well there. You update from 2.5 top 3.4 and immediately see an update for weblinks.

[Troy]

FWIW the upgrade of weblinks from 2.5 was just a bug in the SQL upgrade script and has been fixed with the release of Weblink 3.4.1 earlier this week.

 

• In the long term (and back on topic) I'm too pro-decoupling of the search functionality, if this is feasible at all. But as we are talking about Q3 2016... many things could happen in the meanwhile!

which fails..

Error connecting to the server: SSL certificate problem: unable to get local issuer certificate

Error

Package download failed: https://github.com/joomla-extensions/weblinks/releases/download/3.4.1/pkg_weblinks_3.4.1.zip

Notice

Before updating ensure that the update is compatible with your Joomla! installation.

Pretty much :P

Kind Regards,

George 

--

[Webdongle Elgnodbew]

Tags were added because a vast number of requests were made in the forum.  It was (and is) obvious it is a much wanted feature.

Removing core Components from the default Joomla install will make it less appealing to new cms users.  This de-coupling of core components is another example of how the devs are loosing touch with the users.

[Sergio Manzi]

I agree with you that tagging (and searching , to keep on topic) is a much needed feature for many (most ?) web sites, but my idea is that Joomla (or any other CMS) should be as modular as possible to pave the way to (possibly better) alternatives.

I understand this is probably unfeasible in the frame of J! 3.x and that's why I think this can be food for thought for J! 4 architecture.

[Bakual]

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

It's most likely an issue with your (and mine) hoster and the cert installed. We're trying to figure it out where it comes from.
The update itself works fine if you download the file and install it manually.

[piotr_cz]

I know that it is possible.

I just believe everybody interested in decoupling should be focused on Joomla v4, where dependency management can be done in sane way, using experience from v3.

So much has changed in dev world since current architecture was designed and Joomla will be decoupling core extensions in v3 to depreciate it at last?

[Cyril Thibout]

Hi

Actually I don't see the point in keeping a not working search component. Both standard and advanced seach components are database based so they rely on the Joomla router (!) to rebuild the urls of each result.

As the router is deeply flawed the results have wrong rewritten urls depending on the component the contents are coming from.

Using external search engines such as Google or else give much better results with almost no effort since the results are based on robots crawls.

Cyril

Le lundi 20 juillet 2015 17:35:02 UTC+2, brian teeman a écrit :

I see that the roadmap has been updated and it says that both the core search components will be decoupled and removed from new installs. 

I get why Smart Search (com_finder) will be decoupled as it has numerous issues but it makes no sense to me at all that we will be shipping a CMS without any core search functionality.

[ssnobben]

Cyril

"Actually I don't see the point in keeping a not working search component."  Can you tell me what point you dont see in keeping a search component in a CMS system? Joomla have invested 1000 of hours to get this working and why should we strip out everything from the CMS system? is that what users want? Ok better for go for Google pages and Google search then and close down Joomla..