Remove references to legacy extension types

Created by: eileenmcnaughton

Originally there were different types of extensions - payment processors, reports & modules. For a long time only modules have been recommended and I feel documenting the others only adds confusion.

@mattwire @totten - does this seem right?

Created by: totten

@eileenmcnaughton I'd also be a bit conscientious about people who consult docs when using/patching a previously-published/previously-deployed add-on.

But the importance can probably be guaged with a more data-driven approach -- eg if we grep universe or search the extension directory (cv ext:list -R --dev --columns=key,type --filter-ver=4.6.0 | grep -v module, etal), then it only shows three extensions that reference old-style schema:

• uk.co.circleinteractive.payment.sagepay
• uk.co.vedaconsulting.payment.gocardlessdd
• me.twomice.civicrm.aggregatehouseholdcontributions

That's not big number, but generally published extensions are the tip of the ice-berg.

Opinion: let's go ahead with removal/de-cluttering but add a note like:

!!! tip "Legacy extensions: Payment, Report, Search"
      Historically, CiviCRM v3.x-4.1 strictly categorized extensions as "Payment", "Report", or "Search" -- which required additional XML tags. These have been phased out during the 4.x cycle, and they are no longer documented here. For archival documentation, see [CRMDOC46: Extension Reference](https://wiki.civicrm.org/confluence/display/CRMDOC46/Extension+Reference).

Looks good - it's what I thought was correct anyway! Agree with @totten about adding the tip there.

Created by: seancolsen

Ok I have some thoughts...

• Thanks for cleaning this up @eileenmcnaughton !
• If we're going to proceed with this approach, I've added to commits which, as far as I'm concerned, make this merge-ready.
  • I added the tip from @totten (good thinking!)
  • In bd04c077 I removed some other parts of the info-xml page which still referenced <typeInfo>. I take it from @eileenmcnaughton's commit removing the whole <typeInfo> element, that all of its children elements are now deprecated. There were still a couple of these elements left on the page which I removed. And I also removed the reference to <typeInfo> from within the <extension> element.
• I'm cool with merging as-is, but it also occurred to me to address this out-of-date doc by marking the relevant elements as "deprecated", and putting a note about it in the changelog within that page. We also even have <downloadUrl> which you can see is marked as deprecated. Would that be a better approach? Or maybe not? ...Because maybe "deprecated" is the wrong word because these elements no longer function at all? Would there be a better word?

Again I'm fine merging as-is but would like feedback from others on my final point above before moving forward.

Side note: This might be a fun time to point out that I've been doing some thinking about how we can validate our XML files (and generate docs from the validation schema definition). And I even created an RNG file to validate the database table definition XML. It actually works, and shows some out-of-place elements!

Created by: eileenmcnaughton

I think the elements are old enough that we can remove & refer to the page https://wiki.civicrm.org/confluence/display/CRMDOC46/Extension+Reference them rather than mark as deprecated but I like the idea of adding a note to the change log about them.

Good thinking about xml validation!

Created by: totten

@seanmadsen

• I went through the same thought about simply marking the items deprecated. OTOH, it's been 5 years since v4.2.0 (when we started telling people to do everything as module), and there's also value in de-cluttering the docs, so I sorta agree with Eileen's inclination to remove, and the new tip/hyperlink should address lingering issues of completeness.
• Clarification/Nitpick:<downloadUrl> is an odd one -- it's not really deprecated. It's just outta-sight/outta-mind for most devs. The change circa 4.2.x was in shifting responsibility for it. Extension developers should not code it by hand; instead, civicrm.org injects <downloadUrl>. It's still important, and there's nothing replacing it right now.
• (Update) Nice progress toward validation!

Created by: seancolsen

Awesome. Thanks everyone