.github/workflows/stale.yml

+name: Mark stale issues and pull requests
+
+on:
+  schedule:
+  - cron: "0 * * * *"
+
+jobs:
+  stale:
+
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/stale@v3
+      with:
+        repo-token: ${{ secrets.GITHUB_TOKEN }}
+        stale-issue-message: 'This issue has had no activity in 60 days and has been marked as stale, it will not be closed.'
+        stale-pr-message: 'This pull request has had no activity in 60 days and has been marked as stale, it will not be closed.'
+        stale-issue-label: 'no-issue-activity'
+        stale-pr-label: 'no-pr-activity'
+        days-before-stale: 60
+        days-before-close: -1
+        exempt-issue-labels: 'awaiting-approval,work-in-progress'
+        exempt-pr-labels: 'awaiting-approval,work-in-progress'
+        remove-stale-when-updated: 'True'

.gitignore

+site
+.idea
+*~

LICENSE.txt

+Creative Commons Legal Code
+
+Attribution-ShareAlike 3.0 Unported
+
+    CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
+    LEGAL SERVICES. DISTRIBUTION OF THIS LICENSE DOES NOT CREATE AN
+    ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
+    INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
+    REGARDING THE INFORMATION PROVIDED, AND DISCLAIMS LIABILITY FOR
+    DAMAGES RESULTING FROM ITS USE.
+
+License
+
+THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE
+COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY
+COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS
+AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.
+
+BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE
+TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY
+BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS
+CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND
+CONDITIONS.
+
+1. Definitions
+
+ a. "Adaptation" means a work based upon the Work, or upon the Work and
+    other pre-existing works, such as a translation, adaptation,
+    derivative work, arrangement of music or other alterations of a
+    literary or artistic work, or phonogram or performance and includes
+    cinematographic adaptations or any other form in which the Work may be
+    recast, transformed, or adapted including in any form recognizably
+    derived from the original, except that a work that constitutes a
+    Collection will not be considered an Adaptation for the purpose of
+    this License. For the avoidance of doubt, where the Work is a musical
+    work, performance or phonogram, the synchronization of the Work in
+    timed-relation with a moving image ("synching") will be considered an
+    Adaptation for the purpose of this License.
+ b. "Collection" means a collection of literary or artistic works, such as
+    encyclopedias and anthologies, or performances, phonograms or
+    broadcasts, or other works or subject matter other than works listed
+    in Section 1(f) below, which, by reason of the selection and
+    arrangement of their contents, constitute intellectual creations, in
+    which the Work is included in its entirety in unmodified form along
+    with one or more other contributions, each constituting separate and
+    independent works in themselves, which together are assembled into a
+    collective whole. A work that constitutes a Collection will not be
+    considered an Adaptation (as defined below) for the purposes of this
+    License.
+ c. "Creative Commons Compatible License" means a license that is listed
+    at https://creativecommons.org/compatiblelicenses that has been
+    approved by Creative Commons as being essentially equivalent to this
+    License, including, at a minimum, because that license: (i) contains
+    terms that have the same purpose, meaning and effect as the License
+    Elements of this License; and, (ii) explicitly permits the relicensing
+    of adaptations of works made available under that license under this
+    License or a Creative Commons jurisdiction license with the same
+    License Elements as this License.
+ d. "Distribute" means to make available to the public the original and
+    copies of the Work or Adaptation, as appropriate, through sale or
+    other transfer of ownership.
+ e. "License Elements" means the following high-level license attributes
+    as selected by Licensor and indicated in the title of this License:
+    Attribution, ShareAlike.
+ f. "Licensor" means the individual, individuals, entity or entities that
+    offer(s) the Work under the terms of this License.
+ g. "Original Author" means, in the case of a literary or artistic work,
+    the individual, individuals, entity or entities who created the Work
+    or if no individual or entity can be identified, the publisher; and in
+    addition (i) in the case of a performance the actors, singers,
+    musicians, dancers, and other persons who act, sing, deliver, declaim,
+    play in, interpret or otherwise perform literary or artistic works or
+    expressions of folklore; (ii) in the case of a phonogram the producer
+    being the person or legal entity who first fixes the sounds of a
+    performance or other sounds; and, (iii) in the case of broadcasts, the
+    organization that transmits the broadcast.
+ h. "Work" means the literary and/or artistic work offered under the terms
+    of this License including without limitation any production in the
+    literary, scientific and artistic domain, whatever may be the mode or
+    form of its expression including digital form, such as a book,
+    pamphlet and other writing; a lecture, address, sermon or other work
+    of the same nature; a dramatic or dramatico-musical work; a
+    choreographic work or entertainment in dumb show; a musical
+    composition with or without words; a cinematographic work to which are
+    assimilated works expressed by a process analogous to cinematography;
+    a work of drawing, painting, architecture, sculpture, engraving or
+    lithography; a photographic work to which are assimilated works
+    expressed by a process analogous to photography; a work of applied
+    art; an illustration, map, plan, sketch or three-dimensional work
+    relative to geography, topography, architecture or science; a
+    performance; a broadcast; a phonogram; a compilation of data to the
+    extent it is protected as a copyrightable work; or a work performed by
+    a variety or circus performer to the extent it is not otherwise
+    considered a literary or artistic work.
+ i. "You" means an individual or entity exercising rights under this
+    License who has not previously violated the terms of this License with
+    respect to the Work, or who has received express permission from the
+    Licensor to exercise rights under this License despite a previous
+    violation.
+ j. "Publicly Perform" means to perform public recitations of the Work and
+    to communicate to the public those public recitations, by any means or
+    process, including by wire or wireless means or public digital
+    performances; to make available to the public Works in such a way that
+    members of the public may access these Works from a place and at a
+    place individually chosen by them; to perform the Work to the public
+    by any means or process and the communication to the public of the
+    performances of the Work, including by public digital performance; to
+    broadcast and rebroadcast the Work by any means including signs,
+    sounds or images.
+ k. "Reproduce" means to make copies of the Work by any means including
+    without limitation by sound or visual recordings and the right of
+    fixation and reproducing fixations of the Work, including storage of a
+    protected performance or phonogram in digital form or other electronic
+    medium.
+
+2. Fair Dealing Rights. Nothing in this License is intended to reduce,
+limit, or restrict any uses free from copyright or rights arising from
+limitations or exceptions that are provided for in connection with the
+copyright protection under copyright law or other applicable laws.
+
+3. License Grant. Subject to the terms and conditions of this License,
+Licensor hereby grants You a worldwide, royalty-free, non-exclusive,
+perpetual (for the duration of the applicable copyright) license to
+exercise the rights in the Work as stated below:
+
+ a. to Reproduce the Work, to incorporate the Work into one or more
+    Collections, and to Reproduce the Work as incorporated in the
+    Collections;
+ b. to create and Reproduce Adaptations provided that any such Adaptation,
+    including any translation in any medium, takes reasonable steps to
+    clearly label, demarcate or otherwise identify that changes were made
+    to the original Work. For example, a translation could be marked "The
+    original work was translated from English to Spanish," or a
+    modification could indicate "The original work has been modified.";
+ c. to Distribute and Publicly Perform the Work including as incorporated
+    in Collections; and,
+ d. to Distribute and Publicly Perform Adaptations.
+ e. For the avoidance of doubt:
+
+     i. Non-waivable Compulsory License Schemes. In those jurisdictions in
+        which the right to collect royalties through any statutory or
+        compulsory licensing scheme cannot be waived, the Licensor
+        reserves the exclusive right to collect such royalties for any
+        exercise by You of the rights granted under this License;
+    ii. Waivable Compulsory License Schemes. In those jurisdictions in
+        which the right to collect royalties through any statutory or
+        compulsory licensing scheme can be waived, the Licensor waives the
+        exclusive right to collect such royalties for any exercise by You
+        of the rights granted under this License; and,
+   iii. Voluntary License Schemes. The Licensor waives the right to
+        collect royalties, whether individually or, in the event that the
+        Licensor is a member of a collecting society that administers
+        voluntary licensing schemes, via that society, from any exercise
+        by You of the rights granted under this License.
+
+The above rights may be exercised in all media and formats whether now
+known or hereafter devised. The above rights include the right to make
+such modifications as are technically necessary to exercise the rights in
+other media and formats. Subject to Section 8(f), all rights not expressly
+granted by Licensor are hereby reserved.
+
+4. Restrictions. The license granted in Section 3 above is expressly made
+subject to and limited by the following restrictions:
+
+ a. You may Distribute or Publicly Perform the Work only under the terms
+    of this License. You must include a copy of, or the Uniform Resource
+    Identifier (URI) for, this License with every copy of the Work You
+    Distribute or Publicly Perform. You may not offer or impose any terms
+    on the Work that restrict the terms of this License or the ability of
+    the recipient of the Work to exercise the rights granted to that
+    recipient under the terms of the License. You may not sublicense the
+    Work. You must keep intact all notices that refer to this License and
+    to the disclaimer of warranties with every copy of the Work You
+    Distribute or Publicly Perform. When You Distribute or Publicly
+    Perform the Work, You may not impose any effective technological
+    measures on the Work that restrict the ability of a recipient of the
+    Work from You to exercise the rights granted to that recipient under
+    the terms of the License. This Section 4(a) applies to the Work as
+    incorporated in a Collection, but this does not require the Collection
+    apart from the Work itself to be made subject to the terms of this
+    License. If You create a Collection, upon notice from any Licensor You
+    must, to the extent practicable, remove from the Collection any credit
+    as required by Section 4(c), as requested. If You create an
+    Adaptation, upon notice from any Licensor You must, to the extent
+    practicable, remove from the Adaptation any credit as required by
+    Section 4(c), as requested.
+ b. You may Distribute or Publicly Perform an Adaptation only under the
+    terms of: (i) this License; (ii) a later version of this License with
+    the same License Elements as this License; (iii) a Creative Commons
+    jurisdiction license (either this or a later license version) that
+    contains the same License Elements as this License (e.g.,
+    Attribution-ShareAlike 3.0 US)); (iv) a Creative Commons Compatible
+    License. If you license the Adaptation under one of the licenses
+    mentioned in (iv), you must comply with the terms of that license. If
+    you license the Adaptation under the terms of any of the licenses
+    mentioned in (i), (ii) or (iii) (the "Applicable License"), you must
+    comply with the terms of the Applicable License generally and the
+    following provisions: (I) You must include a copy of, or the URI for,
+    the Applicable License with every copy of each Adaptation You
+    Distribute or Publicly Perform; (II) You may not offer or impose any
+    terms on the Adaptation that restrict the terms of the Applicable
+    License or the ability of the recipient of the Adaptation to exercise
+    the rights granted to that recipient under the terms of the Applicable
+    License; (III) You must keep intact all notices that refer to the
+    Applicable License and to the disclaimer of warranties with every copy
+    of the Work as included in the Adaptation You Distribute or Publicly
+    Perform; (IV) when You Distribute or Publicly Perform the Adaptation,
+    You may not impose any effective technological measures on the
+    Adaptation that restrict the ability of a recipient of the Adaptation
+    from You to exercise the rights granted to that recipient under the
+    terms of the Applicable License. This Section 4(b) applies to the
+    Adaptation as incorporated in a Collection, but this does not require
+    the Collection apart from the Adaptation itself to be made subject to
+    the terms of the Applicable License.
+ c. If You Distribute, or Publicly Perform the Work or any Adaptations or
+    Collections, You must, unless a request has been made pursuant to
+    Section 4(a), keep intact all copyright notices for the Work and
+    provide, reasonable to the medium or means You are utilizing: (i) the
+    name of the Original Author (or pseudonym, if applicable) if supplied,
+    and/or if the Original Author and/or Licensor designate another party
+    or parties (e.g., a sponsor institute, publishing entity, journal) for
+    attribution ("Attribution Parties") in Licensor's copyright notice,
+    terms of service or by other reasonable means, the name of such party
+    or parties; (ii) the title of the Work if supplied; (iii) to the
+    extent reasonably practicable, the URI, if any, that Licensor
+    specifies to be associated with the Work, unless such URI does not
+    refer to the copyright notice or licensing information for the Work;
+    and (iv) , consistent with Ssection 3(b), in the case of an
+    Adaptation, a credit identifying the use of the Work in the Adaptation
+    (e.g., "French translation of the Work by Original Author," or
+    "Screenplay based on original Work by Original Author"). The credit
+    required by this Section 4(c) may be implemented in any reasonable
+    manner; provided, however, that in the case of a Adaptation or
+    Collection, at a minimum such credit will appear, if a credit for all
+    contributing authors of the Adaptation or Collection appears, then as
+    part of these credits and in a manner at least as prominent as the
+    credits for the other contributing authors. For the avoidance of
+    doubt, You may only use the credit required by this Section for the
+    purpose of attribution in the manner set out above and, by exercising
+    Your rights under this License, You may not implicitly or explicitly
+    assert or imply any connection with, sponsorship or endorsement by the
+    Original Author, Licensor and/or Attribution Parties, as appropriate,
+    of You or Your use of the Work, without the separate, express prior
+    written permission of the Original Author, Licensor and/or Attribution
+    Parties.
+ d. Except as otherwise agreed in writing by the Licensor or as may be
+    otherwise permitted by applicable law, if You Reproduce, Distribute or
+    Publicly Perform the Work either by itself or as part of any
+    Adaptations or Collections, You must not distort, mutilate, modify or
+    take other derogatory action in relation to the Work which would be
+    prejudicial to the Original Author's honor or reputation. Licensor
+    agrees that in those jurisdictions (e.g. Japan), in which any exercise
+    of the right granted in Section 3(b) of this License (the right to
+    make Adaptations) would be deemed to be a distortion, mutilation,
+    modification or other derogatory action prejudicial to the Original
+    Author's honor and reputation, the Licensor will waive or not assert,
+    as appropriate, this Section, to the fullest extent permitted by the
+    applicable national law, to enable You to reasonably exercise Your
+    right under Section 3(b) of this License (right to make Adaptations)
+    but not otherwise.
+
+5. Representations, Warranties and Disclaimer
+
+UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR
+OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY
+KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE,
+INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY,
+FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF
+LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS,
+WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION
+OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.
+
+6. Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE
+LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR
+ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES
+ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS
+BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
+
+7. Termination
+
+ a. This License and the rights granted hereunder will terminate
+    automatically upon any breach by You of the terms of this License.
+    Individuals or entities who have received Adaptations or Collections
+    from You under this License, however, will not have their licenses
+    terminated provided such individuals or entities remain in full
+    compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will
+    survive any termination of this License.
+ b. Subject to the above terms and conditions, the license granted here is
+    perpetual (for the duration of the applicable copyright in the Work).
+    Notwithstanding the above, Licensor reserves the right to release the
+    Work under different license terms or to stop distributing the Work at
+    any time; provided, however that any such election will not serve to
+    withdraw this License (or any other license that has been, or is
+    required to be, granted under the terms of this License), and this
+    License will continue in full force and effect unless terminated as
+    stated above.
+
+8. Miscellaneous
+
+ a. Each time You Distribute or Publicly Perform the Work or a Collection,
+    the Licensor offers to the recipient a license to the Work on the same
+    terms and conditions as the license granted to You under this License.
+ b. Each time You Distribute or Publicly Perform an Adaptation, Licensor
+    offers to the recipient a license to the original Work on the same
+    terms and conditions as the license granted to You under this License.
+ c. If any provision of this License is invalid or unenforceable under
+    applicable law, it shall not affect the validity or enforceability of
+    the remainder of the terms of this License, and without further action
+    by the parties to this agreement, such provision shall be reformed to
+    the minimum extent necessary to make such provision valid and
+    enforceable.
+ d. No term or provision of this License shall be deemed waived and no
+    breach consented to unless such waiver or consent shall be in writing
+    and signed by the party to be charged with such waiver or consent.
+ e. This License constitutes the entire agreement between the parties with
+    respect to the Work licensed here. There are no understandings,
+    agreements or representations with respect to the Work not specified
+    here. Licensor shall not be bound by any additional provisions that
+    may appear in any communication from You. This License may not be
+    modified without the mutual written agreement of the Licensor and You.
+ f. The rights granted under, and the subject matter referenced, in this
+    License were drafted utilizing the terminology of the Berne Convention
+    for the Protection of Literary and Artistic Works (as amended on
+    September 28, 1979), the Rome Convention of 1961, the WIPO Copyright
+    Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996
+    and the Universal Copyright Convention (as revised on July 24, 1971).
+    These rights and subject matter take effect in the relevant
+    jurisdiction in which the License terms are sought to be enforced
+    according to the corresponding provisions of the implementation of
+    those treaty provisions in the applicable national law. If the
+    standard suite of rights granted under applicable copyright law
+    includes additional rights not granted under this License, such
+    additional rights are deemed to be included in the License; this
+    License is not intended to restrict the license of any rights under
+    applicable law.
+
+
+Creative Commons Notice
+
+    Creative Commons is not a party to this License, and makes no warranty
+    whatsoever in connection with the Work. Creative Commons will not be
+    liable to You or any party on any legal theory for any damages
+    whatsoever, including without limitation any general, special,
+    incidental or consequential damages arising in connection to this
+    license. Notwithstanding the foregoing two (2) sentences, if Creative
+    Commons has expressly identified itself as the Licensor hereunder, it
+    shall have all rights and obligations of Licensor.
+
+    Except for the limited purpose of indicating to the public that the
+    Work is licensed under the CCPL, Creative Commons does not authorize
+    the use by either party of the trademark "Creative Commons" or any
+    related trademark or logo of Creative Commons without the prior
+    written consent of Creative Commons. Any permitted use will be in
+    compliance with Creative Commons' then-current trademark usage
+    guidelines, as may be published on its website or otherwise made
+    available upon request from time to time. For the avoidance of doubt,
+    this trademark restriction does not form part of the License.
+
+    Creative Commons may be contacted at https://creativecommons.org/.

README.md

 # CiviCRM Developer Guide
 
+* **Issues have moved to https://lab.civicrm.org/documentation/docs/dev/-/issues**
+* **Submit new merge/pull requests at  https://lab.civicrm.org/documentation/docs/dev**
+
+A documentation guide for people who develop with/for [CiviCRM](https://civicrm.org).
+
 -   [Read published version](http://docs.civicrm.org/dev/en/master)
 -   [Learn how to edit](https://docs.civicrm.org/dev/en/master/documentation/#how-to-edit)
 
-This Developer Guide will likely be merged into the
-[civicrm-core](https://github.com/civicrm/civicrm-core/) repo at some point.
\ No newline at end of file
+# Docs Infrastructure Links
+
+-   [Docs Publisher system and issue queue](https://lab.civicrm.org/documentation/docs-publisher)
+-   [Docs Book definitions for the Docs Publisher](https://lab.civicrm.org/documentation/docs-books)
+-   [Docs Working Group meta issue queue](https://lab.civicrm.org/documentation/meta)

TODO.md

@@ -5,6 +5,9 @@
 * Where should we store deprecated documentation? Should we include it at all?
 * Should we rename `develop.md` (`core/develop.md` vs `extension/develop.md`?)
 
+## Style Guide
+* Add guide for using footnotes 
+
 ## Tasks
 
 * Finish importing [GitHub for CiviCRM](https://wiki.civicrm.org/confluence/display/CRMDOC43/GitHub+for+CiviCRM) to `develop.md` and `develop-deprecated.md`.

bin/hook-summary.py

+#!/usr/bin/env python
+
+import yaml
+import re
+from os.path import dirname, abspath, join
+
+PROJECT_ROOT = dirname(dirname(abspath(__file__)))
+DOCS_ROOT = join(PROJECT_ROOT, 'docs/')
+MKDOCS_YAML_FILE = join(PROJECT_ROOT, 'mkdocs.yml')
+OUTPUT_FILE = join(DOCS_ROOT, 'hooks/', 'list.md')
+HEADER = """# All hooks
+
+<!--
+ -- DO NOT EDIT
+ --
+ -- This entire page is auto-generated by the following command:
+ -- ./bin/hook-summary.py
+ --
+ -->
+
+
+This is an overview list of all available hooks and the event listeners that
+are supported for use outside of core. Any event listeners not listed here
+are not supported for use outside of core & could change without notice
+"""
+
+def findBetween( s, first, last ):
+    start = s.index( first ) + len( first )
+    end = s.index( last, start )
+    return s[start:end]
+
+def getSummary(hookFile):
+    content = open(join(DOCS_ROOT + hookFile), 'r').read()
+    summary = findBetween(content, '## Summary', '##')
+    summary = re.sub('This hook (is)?(was)?', '', summary)
+    summary = re.sub('\s+', ' ', summary).strip()
+    if not (summary.endswith('.')):
+      summary = summary + '.'
+    return summary
+
+output = f = open(OUTPUT_FILE, 'w')
+with open(MKDOCS_YAML_FILE, 'r') as f:
+    doc = yaml.load(f, Loader=yaml.FullLoader)
+    pages = doc["nav"]
+    for section in pages:
+        if "Hooks" in section:
+            hookSection = section.get("Hooks")
+
+output.write(HEADER)
+
+for section in hookSection:
+    categoryHooks = list()
+    category, hookList = section.popitem()
+    if isinstance(hookList, list):
+      for hookDetails in hookList:
+          hookName =  list(hookDetails)[0]
+          if re.match("^(<del>)?hook_civicrm_*", hookName) or re.match("^civi", hookName):
+              categoryHooks.append(hookDetails)
+
+    if len(categoryHooks) > 0:
+        output.write('\n## {}\n\n'.format(category))
+        for hookDetails in categoryHooks:
+            hookName, hookFile = hookDetails.popitem()
+            summary = getSummary(hookFile)
+            hookNameForLink = hookFile.replace('hooks/', '')
+            output.write('* **[{}]({})** - {}\n'.format(hookName, hookNameForLink, summary))

docs/afform/afform-behaviors.md

+## FormBuilder Behaviors
+
+### Overview
+
+Simply put, a **Behavior** extends the functionality of an **entity**.
+Behaviors are PHP classes written by a developer, which can be enabled in the GUI to affect how entities behave on a form.
+
+Each Behavior class declares some configuration metadata which automatically appears in the Afform GUI. The user can
+make selections to enable and configure the behavior.
+
+To enact its functionality, a behavior class can listen to any Civi hook or event, notably `civi.afform.prefill` and `civi.afform.submit`.
+These events are called for every entity on a form, and will include information such as the entity name, type, and any
+behaviors that have been configured for that entity.
+
+### Examples
+
+A good example to emulate is the [Contact Dedupe Behavior](https://github.com/civicrm/civicrm-core/blob/master/ext/afform/core/Civi/Afform/Behavior/ContactDedupe.php).
+
+```php
+class ContactDedupe extends AbstractBehavior implements EventSubscriberInterface {
+```
+
+It starts off by extending the `AbstractBehavior` class, which makes it discoverable to Afform,
+and also implementing `EventSubscriberInterface`, which is the recommended way to subscribe to events. That interface
+requires a `getSubscribedEvents` function:
+
+```php
+  /**
+   * @return array
+   */
+  public static function getSubscribedEvents() {
+    return [
+      'civi.afform.submit' => ['onAfformSubmit', 101],
+    ];
+  }
+```
+
+That registers the callback function named `onAfformSubmit` in the same class, to be called every time an Afform entity
+is about to be saved.
+
+The next 4 functions are part of the `AfformBehavior` interface, and provide enough information for the AfformAdmin GUI
+to show the behavior to the user for configuration:
+
+```php
+  public static function getEntities():array {
+    return \CRM_Contact_BAO_ContactType::basicTypes();
+  }
+
+  public static function getTitle():string {
+    return E::ts('Duplicate Matching');
+  }
+
+  public static function getDescription():string {
+    return E::ts('Update existing contact instead of creating a new one based on a dedupe rule.');
+  }
+
+  public static function getModes(string $entityName):array {
+    ...
+  }
+```
+
+Note that `getEntities` does not simply return "Contact" because Afform considers "Individual", "Household" and "Organization"
+to all be their own entities.
+
+The `getModes` function returns an array of operation modes (in this case dedupe rules) for a particular entity type.
+So if your Behavior can act on more than one entity type as this one can, pay attention to the `$entityName` parameter
+and only return modes relevant to that type of entity (in this case, there are different dedupe rules for "Individual" vs
+"Organization", etc).
+
+Finally, the callback registered with `getSubscribedEvents`:
+
+```php
+  public static function onAfformSubmit(AfformSubmitEvent $event) {
+    $entity = $event->getEntity();
+    $dedupeMode = $entity['contact-dedupe'] ?? NULL;
+    if ($event->getEntityType() !== 'Contact' || !$dedupeMode) {
+      return;
+    }
+    // Apply dedupe rule if contact isn't already identified
+    foreach ($event->records as $index => $record) {
+      $supportedJoins = ['Address', 'Email', 'Phone', 'IM'];
+      $values = $record['fields'] ?? [];
+      foreach ($supportedJoins as $joinEntity) {
+        if (!empty($record['joins'][$joinEntity][0])) {
+          $values += \CRM_Utils_Array::prefixKeys($record['joins'][$joinEntity][0], strtolower($joinEntity) . '_primary.');
+        }
+      }
+      $match = Contact::getDuplicates(FALSE)
+        ->setValues($values)
+        ->setDedupeRule($dedupeMode)
+        ->execute()->first();
+      if (!empty($match['id'])) {
+        $event->setEntityId($index, $match['id']);
+      }
+    }
+  }
+```
+
+This function checks the `contact-dedupe` mode set by the Admin (this is a kebab-case version of the class name)
+and takes action on every record being saved for that entity (normally one entity saves one record, but because of the
+AfRepeat feature, entities should always be treated as if they may be multivalued).

docs/afform/afform-core.md

+# Afform Core
+
+The core of the Afform extension is an AngularJS module factory. Traditionally, to [add a new AngularJS module
+in CiviCRM](../framework/angular/quickstart.md), one must create an `.ang.php` file, a js module file, some
+controllers, components & templates, plus a page route to bootstrap AngularJS and load the module.
+
+Afform Core does all that for you, all you need is a template `.aff.html` file and an optional configuration `.aff.json` file.
+
+## Creating a Form in an Extension
+
+As an extension author, you can define a form along with its default, canonical content.
+Simply create a file `ang/MYFORM.aff.html`. In this example, we create a form named `helloWorld`:
+
+1. Make sure you're in the directory with your extension (`cd /path/to/extension`)
+2. Make an `ang` directory in your extension. (`mkdir ang`)
+3. Add some HTML/JS code to your `aff.html` file. `echo '<div>Hello {{routeParams.name}}</div>' > ang/helloWorld.aff.html`
+4. Add some JSON config to your `aff.json` file. `echo '{"server_route": "civicrm/hello-world"}' > ang/helloWorld.aff.json`
+5. Flush the caches so CiviCRM picks up the new form. `cv flush`
+
+A few things to note:
+
+* The `ang` folder is the typical location for AngularJS modules in CiviCRM extensions.
+* We defined a route `civicrm/hello-world`. This appears in the same routing system used by CiviCRM forms. It also supports properties such as `title` (page title) and `is_public` (defaults to `false`).
+* After creating a new form or file, we should flush the cache.
+* If you're going to actively edit/revise the content of the file, then you should navigate to **Administer > System Settings > Debugging** and disable asset caching.
+* The extension `*.aff.html` represents an AngularJS HTML document. It has access to all the general features of Angular HTML (discussed more later).
+* In AngularJS, there is a distinction between a "module" (unit-of-code to be shared; usually appears as `camelCase`) and a "directive" (a custom HTML element; may appear as `camelCase` or as `kebab-case` depending on context). Afform supports a tactical simplification in which one `*.aff.html` corresponds to one eponymous module and one eponymous directive.
+
+Now that we've created a form, we'll want to determine its URL. As with most CiviCRM forms, the URL depends on the CMS configuration. Here is an example from a local Drupal 7 site:
+
+We can use `cv` to get full URLs for any `civicrm/*` URL like so:
+
+* `cv url "civicrm/hello-world"` returns `http://dmaster.localhost/civicrm/hello-world`
+* `cv url "civicrm/hello-world/#/?name=world"` returns `http://dmaster.localhost/civicrm/hello-world/#/?name=world`
+
+Open the URLs and see what you get.
+
+## Form Overrides
+
+Afform files inside an extension (aka a _"Packaged"_ form), are considered the default state, or _"base"_.
+If you fetch your form via API (e.g. the APIv4 Explorer), `civicrm_api4('Afform', 'get')` will return something like this:
+```
+[
+  {
+    name: "helloWorld" // this corresponds to file name minus .aff.html extensions
+    server_route: "civicrm/hello-world" // as defined in helloWorld.aff.json
+    has_base: true,
+    has_local: false,
+    ...
+  },
+  ...
+]
+```
+
+The calculated field `'has_base'` is **`true`** because the Afform files are packaged in an extension.
+`'has_local'` is **`false`** for now. However, site builders can modify your form without touching your extensnion code
+simply by making a copy of the form in their local files directory. In that case the form would be considered _overridden_
+and Afform would automatically use the local copy in favor of the one on your extension and the same api call would return
+data from the new files with `has_local: true`.

docs/afform/afform-events.md

+## Form Builder Events
+
+### `civi.afform_admin.metadata`
+
+*Alter metadata for the Form Builder GUI*
+
+**Since:** CiviCRM 5.50
+
+**Type:** `GenericHookEvent`
+
+**Params:**
+
+- **`entities`** (array) List of entities that can be used in the Form Builder GUI. Each item has array keys:
+  - `name` (string)
+  - `label` (string)
+  - `icon` (string:"fa-*")
+  - `type` (string:"primary"|"secondary")
+  - `defaults` (string:js object).
+- **`elements`** (array) Static elements that can be added to a form, keyed by name. Each item has array keys:
+  - `title` (string) Title shown in Editor
+  - `afform_type` (array) Form types this element is used for
+  - `element` (array) Default markup for this element
+  - `directive` (string) Specify directive name in dash format (should match `['element']['#tag']`)
+  - `admin_tpl` (string) Editor template. Extensions can provide their own template for editing this element type,
+  by adding an Angular module with base page `'civicrm/admin/afform'`.
+- **`inputTypes`** (array) Form widgets used to represent a field.
+- **`styles`** (array) Bootstrap3 style strings.
+- **`permissions`** (array) Permissions that can be set for an Afform.
+- **`dateRanges`** (array) Date range options.
+
+
+### `civi.afform.prefill`
+
+*Prefill entity data when the form is being viewed.*
+
+**Since:** CiviCRM 5.56
+
+**Type:** `AfformPrefillEvent`
+
+**Methods:**
+
+- **getAfform()**: `array`
+- **getFormDataModel()**: `Civi\Afform\FormDataModel`
+- **getApiRequest()**: `Civi\Api4\Action\Afform\Prefill`
+- **getEntityType()**: `string`
+- **getEntityName()**: `string`
+- **getSecureApi4()**: `callable`
+- **setEntityId(int $index, int $id)**
+- **setJoinIds(int $index, string $joinEntity, array $joinIds)**
+
+
+### `civi.afform.validate`
+
+*Validate submission of an Afform.*
+
+**Since:** CiviCRM 5.56
+
+**Type:** `AfformValidateEvent`
+
+**Methods:**
+
+- **getAfform()**: `array`
+- **getFormDataModel()**: `Civi\Afform\FormDataModel`
+- **getApiRequest()**: `Civi\Api4\Action\Afform\Submit`
+- **getEntityValues()**: `array`
+- **setError(string $errorMsg)**
+
+
+### `civi.afform.submit`
+
+*Handle submission of an `<af-form>` entity (or set of entities in the case of `<af-repeat>`).*
+
+**Since:** CiviCRM 5.31
+
+**Type:** `AfformSubmitEvent`
+
+**Methods:**
+
+- **getAfform()**: `array`
+- **getFormDataModel()**: `Civi\Afform\FormDataModel`
+- **getApiRequest()**: `Civi\Api4\Action\Afform\Submit`
+- **getEntityType()**: `string`
+- **getEntityName()**: `string`
+- **getRecords()**: `array`
+- **getSecureApi4()**: `callable`
+- **setEntityId(int $index, int $id)**
+- **setRecords(array $records)**
+- **setJoinIds(int $index, string $joinEntity, array $joinIds)**

docs/afform/form-builder.md

+Form Builder provides a flexible form interface allowing editing a variety of CiviCRM entities as well as a developer interface.
+
+## Exposing an entity to Form Builder 
+
+### Via event listener
+
+The Form Builder GUI can be extended via the [`civi.afform_admin.metadata`](afform-events.md) event.
+This event is used for adding entities, elements, input types, etc.
+
+### Via an Afform entityType declaration file
+
+It is also possible to expose entities in Form Builder by adding a declaration. To do this:
+
+1. Add the [mixin](../framework/mixin/index.md) `<mixin>afform-entity-php@1.0.0</mixin>` to your extension's `info.xml` file (note: for backward compatability with versions < 5.50 you must [add a shim](https://github.com/eileenmcnaughton/deduper/pull/26).
+2. Ensure the entity in question has apiv4 CRUD entities (these get generated automatically if using [civix with an extension](https://docs.civicrm.org/dev/en/latest/step-by-step/create-entity/#4-generate-sql-dao-and-bao-files))
+3. Create a php file in the following location - `afformEntities/EntityName.php` as you can see [here in the `deduper` extension](https://github.com/eileenmcnaughton/deduper/blob/master/afformEntities/ContactNamePair.php). For more complex examples [see core](https://github.com/civicrm/civicrm-core/tree/master/ext/afform/admin/afformEntities).
+
+```php
+<?php
+
+use CRM_MyExtension_ExtensionUtil as E;
+
+return [
+  'type' => 'primary',
+  'defaults' => "{}",
+  'boilerplate' => [
+    ['#tag' => 'af-field', 'name' => 'name'],
+    ['#tag' => 'af-field', 'name' => 'xxx'],
+  ],
+];
+```
+4. The boilerplate specifies the fields that are automatically added to a new Submission Form. In the example above, the fields 'name' and 'xxx' would be added. 
+5. An entity can be available for "Submission forms" and/or for "Field blocks". In order for the entity to be available for Submission forms, add `'type' => 'primary'` [example](https://github.com/civicrm/civicrm-core/blob/master/ext/afform/admin/afformEntities/Individual.php) or only as Field blocks, leave blank or add `'type' => 'join'` [example](https://github.com/civicrm/civicrm-core/blob/master/ext/afform/admin/afformEntities/Address.php). A Field block (or join) is only available in relation to a primary entity.
+
+[Core afform entities](https://github.com/civicrm/civicrm-core/tree/master/ext/afform/admin/afformEntities) have examples of other parameters that can be added such as `repeat_max`, `unique_fields`, `boilerplate`, `icon`, `alterFields`, and `data` defaults. Be sure to test them out to see what works best with a custom entity.
+
+!!! tip "Making fields available for use in Form Builder"
+    If an expected element for an Entity is missing from Form Builder, it's likely that `input_type` needs to be added to the field. See [Entities](../../framework/entities) for possible values.
+    Find the `getFields` function in the corresponding `.entityType.php` file for that Entity and add an appropriate input type.
+    (for older entities using legacy xml schema files, the corresponding tag would be `<html><type>` and the code generator script would need to be run after updating).

docs/afform/overview.md

+## Introduction
+
+Form-Builder (aka `afform`) is a core extension currently in active development.
+It is intended to become the main building tool for CiviCRM forms and layouts going forwards.
+
+## Embedding
+
+Afforms can be embedded on any CiviCRM page as Angular directives; they also can be configured to
+automatically appear on the dashboard or contact summary screen. Afforms can be embedded into
+other Afforms simply by including the directive for one Afform in the markup of another; Angular
+dependencies will be resolved automatically.
+
+### Embedding in Smarty Templates
+
+*Adding Afforms to traditional Smarty-based pages or forms can be a transitional step away from legacy screens*
+
+**PHP Code**
+```php
+Civi::service('angularjs.loader')
+  ->addModules('afformMyForm');
+
+$this->assign('myAfformVars', $optionalVars);
+```
+
+Note - to figure out what to put in 'name' look at the name in the FormBuilder listing for your form. In the above example the 'name' would be the entire 'afformMyForm' (there isn't a magic prefix).
+
+
+
+**Template Code**
+```
+<crm-angular-js modules="afformMyForm">
+  <form id="bootstrap-theme">
+    <afform-my-form options='{$myAfformVars|@json_encode}'></afform-my-form>
+  </form>
+</crm-angular-js>
+```
+
+## Afform Types
+
+- **form**: A form which submits through the `Afform::submit` api, editable in the form-builder GUI.
+- **block**: A snippet meant to be incorporated into a larger form.
+- **system** (default): Non-editable forms.
+- **search**: An afform with an embedded [SearchKit Display](../searchkit/displays.md) and optional search filter fields.
+
+## Afform markup
+
+Althought angularjs offers extensive functionality it is recommended that, where possible, CiviCRM Angular forms are written using just html and CiviCRM afform markup. The reason being that there is demand to be able to render these forms using different front end libraries (eg. React) and funding is being sought to that end. If this does proceed then the first piece of work is likely to be rendering existing FormBuilder forms via React - something that would work seamlessly if no native
+angularjs markup is used.
+
+The CiviCRM Afform markup includes
+
+
+| Type | Example |Notes |
+| ------ | ------ | ------ |
+| form embedding markup       | `<contact-basic></contact-basic>`        |Embed a FormBuilder form as defined in `contactBasic.aff.html` & `contactBasic.aff.js`|
+| api 3 access markup        |   ```  <div af-api3="af-api3="['Contact','getsingle', {id: options.contact_id}]"   af-api3-ctrl="contact">  </div>  ```   |Call api v3 & assign results to variable `contact`|
+| api 4 access markup        |  ```<div  af-api4="['Afform', 'get', {select: ['name','title','is_public','server_route', 'has_local', 'has_base'], orderBy: {name:'ASC'}}]"  af-api4-ctrl="listCtrl"></div>```       |Call api v4 & assign results to variable `listCtrl`|
+
+
+
+ 
+   

docs/afform/search-forms.md

+A [SearchKit Display](../searchkit/displays.md) can be embedded in an Afform.
+This switches the form fields from "create" to "get" mode so they can work as search filters.
+
+Search Displays embedded in an Afform will use the permissions of the form to determine
+whether they may be viewed; if a user has access to the Afform then SearchKit will grant
+permission to view the Display as well.
\ No newline at end of file

docs/api/ERDs/index.md

+# Entity Relationship Diagrams
+
+Entity Relationship Diagrams provide a different view into how the entities accessed through the API are related to each other.
+
+Most of the entities in APIv4 and APIv3 are mapped directly to tables in the CiviCRM database. A few are not, notably the Order API and the Payment API.
+
+Collected below are a number of Entity-Relationship Diagrams. The diagrams were generated by [DBeaver](https://dbeaver.io/), with notes added manually. Each foreign key relationship that is defined in the database between two tables is represented by a line connecting the tables. A table can also have a relationship with itself, for example, a parent_id field linking to a different record in the same table.
+
+The lines do not indicate the specific fields joined by the relationship unfortunately. The solid circle at the end of a relationship line touches the table that has a foreign key referencing another table. So the solid dot indicates the 'beginning' of the relationship, and is touching the 'source' table. When the foreign key field in the souce table is defined as NOT NULL, then the other end of the relationship line will go straight into the destination table. However, if foreign key field in the source table is optional, then there is a rectangle on the end touching the destination table.
+
+CiviCRM has a field naming convention that helps in determining which field is a foreign key to a different table. A table named civicrm_tablename1 has a field named id as its unique primary key. References from other tables to that id field are named tablename1_id. (There are a few exceptions, such as when two fields in one table reference the key of a single other table, for different purposes.)
+
+CiviCRM has non-standard patterns that it uses to implement one table  references one amongst several other tables. We term this a pseudo foreign key. In most cases there is a pair of fields, entity_table and entity_id, with entity_table containing the name of the table being referenced and entity_id representing the value of id of the record in that field being referenced. A different pattern is present in the civicrm_value_* tables that are dynamically created to store custom fields that extend various entities in CiviCRM. In that case, entity_id present in the table, and the entity_table value is found in the appropriate civicrm_custom_group.extends field.
+
+To aid in viewing and understanding the 200+ tables in CiviCRM, each diagram collects a handful of related tables.
+
+For convenience, here is a clickable list of the Entity-Relationship Diagrams below:
+
+- [ACLs](#acls)
+- [Activities](#activities)
+- [Batches and Queues](#batches-and-queues)
+- [Cases](#cases)
+- [Contact Info](#contact-info)
+- [Contribution Financial](#contribution-financial)
+- [Contribution Page](#contribution-financial)
+- [Contributions recur](#contributions-recur)
+- [Custom Fields](#custom-fields)
+- [Deduping](#deduping)
+- [External Providers](#external-providers)
+- [Groups, Tags and Campaigns](#groups-tags-and-campaigns)
+- [Interfaces](#interfaces)
+- [Line Items](#line-items)
+- [Mailings](#mailings)
+- [Participants](#participants)
+- [Pledges](#pledges)
+- [Price fields and Premiums](#price-fields-and-premiums)
+- [Relationships](#relationships)
+- [System](#system)
+
+
+## ACLs
+
+ACLs are Access Control Lists that define permissions that a user has to view data of different sorts.
+
+![ACLs](../../img/ERDs/ACLs.png)
+
+## Activities
+
+![Activities](../../img/ERDs/Activities.png)
+
+The purpose of an Activity is specific to the activity_type. There can be custom fieldset defined for Activities, including for specific types. 
+
+## Batches and Queues
+
+![Batches and Queues](../../img/ERDs/Batches_and_Queues.png)
+
+The queue and queue_item tables are general purpose, and helpful when long-running processes need to have a backlog of tasks. The batch table was originally created to support financial batches, both those created by navigating to Contributions > Batch Data Entry, and ones created manually at Contributions > Accounting Batches > New Batch.
+
+## Cases
+
+![Cases](../../img/ERDs/Cases.png)
+
+These are the primary tables used by CiviCase, though it also makes extensive use of Activities.
+
+## Contact Info
+
+![Contact Info](../../img/ERDs/Contact_Info.png)
+
+This diagram illustrates the various tables containing contact information. These tables are more normalized than some schemas in data sources that contain multiple fields for the same type of content, for example, email1 and email2 or phone1 and phone2.
+
+## Contribution Financial
+
+![Contribution Financial](../../img/ERDs/Contribution_Financial.png)
+
+This diagram includes tables related to accounting information for contributions, memberships and event registrations. Double entry bookkeeping is represented by debit and credit accounts in  civicrm_financial_trxn and civicrm_financial_item for most entries, and occasionally for some simple transactions by the from and to account fields in civicrm_financial_trxn. These are the authoritative entries for auditing purposes. The amount fields in civicrm_contribution and civicrm_line_item are often more convenient for some reporting purposes. However, the civicrm_contribution.financial_type_id table is a deprecated field since it cannot accurately represent transactions with multiple line items with different financial types.
+
+## Contribution Page
+
+![Contribution Page](../../img/ERDs/Contribution_Page.png)
+
+This diagram includes tables that store the settings defined when useing Contributions > Manage Contribution Page, and under Contributions > Manage Price Sets.
+
+## Contributions recur
+
+![Contributions recur](../../img/ERDs/Contributions_recur.png)
+
+Recurring contributions, and memberships that are paid with them, are illustrated here.
+
+## Custom Fields
+
+![Custom Fields](../../img/ERDs/Custom_Fields.png)
+
+CiviCRM databases typically have many sets of custom fields defined, and many tables named civicrm_value_*.
+
+## Deduping
+
+![Deduping](../../img/ERDs/Deduping.png)
+
+The dedupe_rule_group has one record per rule in the user interface at Contacts > Find and Merge Duplicate Contacts. The dedupe_rule table has one row per 'field' entry for a particular rule. 
+
+## External Providers
+
+![External Providers](../../img/ERDs/External_Providers.png)
+
+These tables are used to store information used to connect to some standard external services.
+
+## Groups, Tags and Campaigns
+
+![Groups, Tags and Campaigns](../../img/ERDs/Groups__Tags_and_Campaigns.png)
+
+Groups, Tags and Campaigns help to segment and relate entities in CiviCRM.
+
+## Interfaces
+
+![Interfaces](../../img/ERDs/Interfaces.png)
+
+These tables define some menu and navigation elements in CiviCRM and permissions for users to see them.
+
+## Line Items
+
+![Line Items](../../img/ERDs/Line_Items.png)
+
+There may be one or more line items related to a contribution, and each may relate to a membership, event registration or a different purpose.
+
+## Mailings
+
+![Mailings](../../img/ERDs/Mailings.png)
+
+CiviMail is a powerful bulk emailing solution. Some of the tables in this diagram relate to the content of the emails, others are used during sending, and the remainder contain information on recipients interactions with those emails.
+
+## Participants and Events
+
+![Participants](../../img/ERDs/Participants.png)
+
+Participants register in events. The registrations are stored in the same tables regardless of whether the event is paid or free.
+
+## Pledges
+
+![Pledges](../../img/ERDs/Pledges.png)
+
+Pledges are prototypically used during capital campaigns to store promises to donate a certain amount over a period of time through payments to be specified later. When payments are made against the pledge, it reduces the amount owing.  
+
+## Price fields and Premiums
+
+![Price fields](../../img/ERDs/Price_fields.png)
+
+Price fields are part of the configuration of what people can buy or donate to through a CiviCRM site. Price_field_values are the options for certain types of price_fields; other price field types like a text entry field for an amount do not require price_field_values.
+
+Premiums are used by fundraisers to incentivize people to donate more, with products representing things like mugs or Tshirts that are given away for donating over a certain level.
+
+## Relationships
+
+![Relationships](../../img/ERDs/Relationships.png)
+
+Relationships can be created between contacts. Relationship types can be used to limit which contacts can be involved in a relationship (eg only organizations can be employers and only individuals can be employees). Relationships can be used to define permissions, for example, parents can be allowed to see and edit their children's information.
+
+## System
+
+![System](../../img/ERDs/System.png)
+
+This diagram includes some of the more important system tables.

docs/api/general.md

-# The CiviCRM API
-
-CiviCRM has a stable comprehensive **API** (Application Programming
-Interface) that can be used to access and manage data in CiviCRM. The
-API is the recommended way for any CiviCRM extension, CMS module, or
-external program to interact with CiviCRM.
-
-Utilizing the API is superior to accessing core functions directly (e.g.
-calling raw SQL, or calling functions within the BAO files)
-because the API offers a consistent interface to CiviCRM's features. It is
-designed to function predictably with every new release so as to preserve
-backwards compatibility of the API for several versions of CiviCRM. If
-you decide to use other ways to collect data (like your own SQL statements),
-you risk running into future problems when changes to the schema and
-BAO arguments inevitably occur.
-
-The best place to begin working with the API is your own ***test*** install of
-CiviCRM, using the API explorer and the API parameter list.
-
-
-## API explorer
-
-The API explorer gives you the possibility to actually
-try out the API in action and is available at
-
-```text
-http://[CIVICRM\_URL]/civicrm/api/explorer
-```
-
-You can select the entity you want to
-use, for example `Contact` and the action you want to perform, for
-example `Get`. Again, be careful as the API explorer will actually
-perform your actions! So if you delete a contact to check what API
-call to use, it will really delete the contact. The API explorer
-will show you the specific code necessary to execute the API call you
-have been testing.
-
-Try out the [API explorer on the demo site], *after you login as demo/demo*.
-
-[API explorer on the demo site]: http://drupal.sandbox.civicrm.org/civicrm/api/explorer
-
-
-## API parameter list
-
-The API parameter list shows all available entities which
-can be manipulated by the API and is available at:
-
-```text
-http://[CIVICRM_URL]/civicrm/api/doc
-```
-
-You will first get a list of all the API entities.
-If you click on an entity you will get a list of parameters that are
-available for that specific entity, with the type of the parameter.
-This can be very useful if you want to check what you can retrieve
-with the API and what parameters you can use to refine your get
-action or complete your create or update action.
-
-
-## API Examples
-
-CiviCRM ships with API examples included in the distribution. You can
-find the examples specific to your installed version at:
-
-`<civicrm_root>/api/v3/examples`
-
-[Explore these examples on GitHub](https://github.com/civicrm/civicrm-core/tree/master/api/v3/examples)
-
-
-## Changelog
-
-All important changes made to the API are be recorded on the wiki at:
-[API changes](https://wiki.civicrm.org/confluence/display/CRMDOC/API+changes)

docs/api/index.md

+# The CiviCRM API
+
+CiviCRM has a stable, comprehensive **API** (Application Programming Interface) for accessing and managing data.
+The API is the recommended way for any extension or external program to interact with CiviCRM.
+CiviCRM also uses its own API to power all new UIs and bundled extensions.
+
+Extensions can provide additional API entities or functionality. For help creating your own additions to the API, see [API Architecture](v4/architecture.md).
+
+!!! tip "Why Use the API"
+    The API is superior to executing raw SQL or calling internal CiviCRM functions, because it offers consistency and stability.
+    It is designed to function predictably with every new release so as to preserve backwards compatibility when changes to the schema and BAO functions inevitably occur.
+    Using the API also ensures all hooks and events are dispatched, allowing CiviCRM business logic and 3rd party integrations to function properly.
+
+The best place to begin working with the API is your own *test* install of CiviCRM, using the API Explorer.
+
+## API Explorer
+
+This is the go-to tool for both new and experienced developers. It gives detailed, interactive documentation on each entity, including the
+available actions and their parameters, and will write API code for you. To access it:
+
+1. Log in to a CiviCRM site as an administrator.
+    * This can even be the [demo site](http://dmaster.demo.civicrm.org/).
+2. Within the CivCRM menu, go to **Support > Developer** and either **API Explorer v4** (URL `/civicrm/api4`) or the legacy **API Explorer v3** (URL `/civicrm/api3`).
+
+!!! warning
+    The API Explorer executes real API calls. It can modify data! So if you execute a `Contact` `delete` call, it will really delete the contact.
+    As such, any experimenting is best done within a test site.
+
+To get started, select an entity, for example `Contact` and an action to perform, for example `Get`.
+Use the GUI to select additional parameters to configure your API call; as you do, the API Explorer will generate code
+which you can copy & paste into your PHP, Javascript, REST or CLI application.
+
+## API Versions
+
+CiviCRM's API has major versions which are independent of the CiviCRM version. The API version increments more slowly in order to maintain stability within the extension ecosystem.
+Typically, two versions of the API are maintained concurrently to allow gradual transitions. New releases of CiviCRM may add features to the API but will not break backward-compatibility within an API version.
+
+- [**APIv4**](v4/usage.md) is the current stable version, with new features being actively developed.
+- [**APIv3**](v3/usage.md) is minimally maintained with no new features and regression bug-fixes only.
+
+Your code can use a combination of v3 and v4 API calls, but v4 is recommended for all new projects.
+Although there are no plans at the time of this writing to remove APIv3, [upgrading existing code](v4/differences-with-v3.md) to use APIv4 is a good way to future-proof extensions.
+
+## Changelog
+
+All important changes made to the API are recorded in [APIv3 changes](v3/changes.md) and [APIv4 changes](v4/changes.md).
+
+## Entity Relationship Diagrams
+
+To make better use of the API, it can be helpful to have a visual understanding of the relationship between entities available in the API. [Entity Relationship Diagrams](ERDs/index.md) illustrating many of these are available as supplementary documentation to the API Explorer.
\ No newline at end of file

docs/api/actions.md → docs/api/v3/actions.md

-# API Actions
+# APIv3 Actions
+
+!!! warning "APIv3 Deprecation"
+    API version 3 is now deprecated. [Version 4](../v4/actions.md) is recommended.
 
 Most entities support the following actions:
 
@@ -42,7 +45,7 @@ Fetch entity metadata, i.e. the list of fields supported by the entity
 ## getlist
 
 Used for autocomplete lookups by the
-[entityRef](https://wiki.civicrm.org/confluence/display/CRMDOC/EntityRef+Fields) widget
+[entityRef](./../../framework/quickform/entityref.md) widget
 
 ## getoptions
 
@@ -61,7 +64,7 @@ returns
 array(
   1 => 'Female',
   2 => 'Male',
-  3 => 'Transgender'
+  3 => 'Other'
 )
 ```
 
@@ -74,6 +77,31 @@ Replace an old set of records with a new or modified set of records.
 Warning - REPLACE includes an implicit delete - use with care & test well
 before using in productions
 
+## getunique
+
+Returns all unique fields (other than 'id' field) for a given entity.
+```php
+civicrm_api3('Contribution', 'getunique');
+```
+
+return 
+
+```php
+{
+    "is_error": 0,
+    "version": 3,
+    "count": 2,
+    "values": {
+        "UI_contrib_trxn_id": [
+            "trxn_id"
+        ],
+        "UI_contrib_invoice_id": [
+            "invoice_id"
+        ]
+    }
+}
+```
+
 ## <del>setvalue</del>
 
 **Deprecated.** Use the create action with the param 'id' instead.

docs/api/chaining.md → docs/api/v3/chaining.md

-# API Chaining
+# APIv3 Chaining
 
-It is now possible to do two API calls at once with the first call feeding into
-the second. E.g. to create a contact with a contribution you can nest the
-contribution create into the contact create. Once the contact has been created
-it will action the contribution create using the id from the contact create as
-`contact_id`. Likewise you can ask for all activities or all contributions to
-be returned when you do a get.
+!!! warning "APIv3 Deprecation"
+    API version 3 is now deprecated. [Version 4](../v4/chaining.md) is recommended.
 
-See [api/v3/examples] within the core source code for a plethora of examples
-(from unit tests) that use API chaining. To start, look at these examples:
+It is possible to do two API calls at once with the first call feeding into the second. E.g. to create a contact with a contribution you can nest the contribution create into the contact create. Once the contact has been created it will action the contribution create using the id from the contact create as `contact_id`. Likewise you can ask for all activities or all contributions to be returned when you do a `get`.
 
--   [APIChainedArray.php]
--   [APIChainedArrayFormats.php]
--   [APIChainedArrayValuesFromSiblingFunction.php]
-
-[api/v3/examples]: https://github.com/civicrm/civicrm-core/tree/master/api/v3/examples
-[APIChainedArray.php]: https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/Contact/APIChainedArray.php
-[APIChainedArrayFormats.php]: https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/Contact/APIChainedArrayFormats.php
-[APIChainedArrayValuesFromSiblingFunction.php]: https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/Contact/APIChainedArrayValuesFromSiblingFunction.php
+See [api/v3/examples](https://github.com/civicrm/civicrm-core/tree/master/api/v3/examples) within the core source code for a plethora of examples (from unit tests) that use chaining. To start, look at these examples:
 
+-   [APIChainedArray.php](https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/Contact/APIChainedArray.ex.php)
+-   [APIChainedArrayFormats.php](https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/Contact/APIChainedArrayFormats.ex.php)
+-   [APIChainedArrayValuesFromSiblingFunction.php](https://github.com/civicrm/civicrm-core/blob/master/api/v3/examples/Contact/APIChainedArrayValuesFromSiblingFunction.ex.php)
 
 Note that there are a few supported syntaxes:
 
@@ -71,6 +62,4 @@ civicrm_api('Contact', 'create', array(
 
 The format you use on the way in will dictate the format on the way out.
 
-Currently this supports any entity and it will convert to `entity_id` -
-i.e. a PledgePayment inside a contribution will receive the `contribution_id`
-from the outer call.
+Currently this supports any entity and it will convert to `entity_id` - i.e. a PledgePayment inside a contribution will receive the `contribution_id` from the outer call.

docs/api/v3/changes.md

+# APIv3 Changelog
+
+!!! warning "APIv3 Deprecation"
+    API version 3 is now deprecated. [Version 4](../v4/changes.md) is recommended.
+
+*This page lists additions to the APIv3 with each new release of CiviCRM Core.*
+
+Also see: [Differences Between Api v3 and v4](../v4/differences-with-v3.md) and [Hooks Changelog](../../hooks/changes.md).
+
+## APIv3: Framework
+
+### 5.47 Migration from `extern/rest.php` to `civicrm/ajax/rest` {:#restendpoint}
+
+The traditional [APIv3 REST end-point](rest.md#end-point-url), `extern/rest.php`, is not supported by some common environments and lacks some newer features.
+
+As of v5.47, `civicrm/ajax/rest` may be used as a drop-in replacement.  It supports a wider range of environments and authentication protocols.
+
+For a minimal migration, change the URL. For a full migration, you may also change the authentication protocol.
+
+??? question "Change URL to `civicrm/ajax/rest` (Reasons)"
+
+    1. Stop maintaining manual copy of `extern/rest.php`.
+    2. Improve compatibility with upgraded, migrated, or reconfigured CMS.
+
+??? example "Change URL to `civicrm/ajax/rest` (Example)"
+
+    On the CiviCRM server, enable the extension [AuthX](../../framework/authx.md). (*Navigate to "Administer => System Settings => Extensions" and enable "AuthX".*)
+
+    On the CiviCRM client, change the URL. Suppose you were sending requests via `curl`. The old request was:
+
+    ```bash
+    curl -X 'POST' -d 'entity=Contact&action=get&json=1&key=MY_SITE_KEY&api_key=MY_API_KEY' \
+      'http://example.org/sites/all/modules/civicrm/extern/rest.php'
+    ```
+
+    The new request would be:
+
+    ```bash
+    curl -X 'POST' -d 'entity=Contact&action=get&json=1&key=MY_SITE_KEY&api_key=MY_API_KEY' \
+      'http://example.org/civicrm/ajax/rest'
+    ```
+
+    Here are a few more examples of old and new URLs:
+
+    ```
+    /* Old URLs */
+    https://backdrop.example.org/modules/civicrm/extern/rest.php
+    https://drupal.example.org/sites/all/modules/civicrm/extern/rest.php
+    https://wordpresss.example.org/wp-content/plugins/civicrm/civicrm/extern/rest.php
+
+    /* New URLs */
+    https://backdrop.example.org/civicrm/ajax/rest
+    https://drupal.example.org/civicrm/ajax/rest
+    https://wordpress.example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm/ajax/rest
+    ```
+
+    <!-- FIXME: Can we rely on WP clean URLs for this? -->
+    <!-- Haven't tested Joomla. Expecting http://joomla.example.org/administrator/index.php?option=com_civicrm&task=civicrm/ajax/rest&reset=1 -->
+
+??? question "Change authentication protocol (Reasons)"
+
+    1. __Remove dependence on `CIVICRM_SITE_KEY`. Use role-based access-control.__
+
+        AuthX does not require sharing `CIVICRM_SITE_KEY`.  Instead, you configure access-control by granting or revoking permissions
+        (`authenticate with api key` and/or `authenticate with password`).
+
+    2. __Support username/password, JWT, and/or API key.__
+
+        API keys are great - but not always. AuthX still accepts API keys -- but it also supports JSON Web Tokens (*by default*)
+        and usernames/passwords (*requires opt-in*).
+
+    3. __Support more authentication flows (with more correct session-management).__
+
+        Legacy REST performed authentication with HTTP parameters (`?key=...&api_key=...`).  This looked like a "stateless HTTP" style, but
+        it often left behind extraneous records in session-storage.  AuthX supports both stateless styles (eg HTTP parameters and HTTP
+        headers) and stateful styles (eg HTTP login/session).  Stateless styles do not leave behind extraneous records in session-storage.
+
+    4. __Support a wide range of CiviCRM end-points.__
+
+        Legacy REST authentication only supported APIv3. With AuthX, you may access any `civicrm/ajax/*` end-point.
+
+??? example "Change authentication protocol (Example)"
+
+    Legacy REST authentication is very similar to AuthX's "HTTP Parameter" authentication. Here are the steps to switch:
+
+    1. Change the URL to `civicrm/ajax/rest`, as described earlier.
+
+    2. On the CiviCRM server, verify the settings. Navigate to "Administer => System Settings => Authentication". "HTTP
+       Parameter" should accept credentials of type "API Key". (*This should be enabled by default.*)
+
+    3. On the CiviCRM server, ensure that appropriate users have permission `authenticate with api key`.
+
+    4. On the CiviCRM client, remove `?key=...&api_key=...`. Add `?_authx=...`. For an API key, the value must begin with `Bearer`.
+
+        ```bash
+        ## Legacy REST authentication
+        curl -X 'POST' -d 'entity=Contact&action=get&json=1&key=MY_SITE_KEY&api_key=MY_API_KEY' \
+          'http://example.org/civicrm/ajax/rest'
+
+        ## AuthX HTTP parameter authentication
+        curl -X 'POST' -d 'entity=Contact&action=get&json=1&_authx=Bearer+MY_API_KEY' \
+          'http://example.org/civicrm/ajax/rest'
+        ```
+
+### 5.12 Support for string 'NULL' as an accepted value for custom data fields
+
+The API has now been changed such that when setting the value of a custom field using the API if you pass the string 'NULL' then it will set the field value to be the String NULL not the database NULL. If you want the value to be truely NULL then you need to either not pass in the value or use 'null' instead
+
+### 5.8 Support for Extension Examples in the API Explorer.
+
+From 5.8 it is now possible for Extension authors to store examples for their API entities in a folder `<extensiondir>/api/v3/examples/<entity>/<file>` in the same structure as is in core. They will now be displayed in the API Explorer just like the core examples.
+
+### 5.0 Support for custom data on any entity via the api
+It is now possible to add any (almost) entity to the cg_group_extends option group and create / retrieve custom data for that field via the api (also custom entities). Ones that do not work as of 5.0 release are       
+      'CaseContact',
+      'CustomField',
+      'CustomGroup',
+      'DashboardContact',
+      'Domain',
+      'File',
+      'FinancialType',
+      'LocBlock',
+      'MailingEventConfirm',
+      'MailingEventResubscribe',
+      'MailingEventSubscribe',
+      'MailingEventUnsubscribe',
+      'MailingJob',
+      'MembershipPayment',
+      'SavedSearch',
+      'UFJoin',
+      'UFField',
+      'PriceFieldValue',
+      'GroupContact',
+      'EntityTag',
+      'PledgePayment',
+
+### 5.0 Support for Serialization Metadata ###
+A field defined with the key 'serialize' (in the metadata) will be serialized on save/create with no additional handling if using basic create methods. Generally this is used by adding `<serialize>JSON</serialize>` to the xml when generating the DAO. [Example declaration](https://github.com/eileenmcnaughton/org.wikimedia.geocoder/blob/master/CRM/Geocoder/DAO/Geocoder.php#L259)
+
+### 4.7.17: OR Operator
+
+Most API "get" operations (with the exception of some nonstandard entities - Contact, Contribution, Pledge & Participant) [now support the OR operator](https://issues.civicrm.org/jira/browse/CRM-20034). Use the API Explorer to see the syntax. ![Example use of API Or functionality](../../img/api4/api-or-example.png)
+
+### 4.7.13: Standardized output of EntityTag api
+
+The EntityTag api had nonstandard output which indexed results by the `tag_id` column instead of the id column. This was [cleaned up as part of permission fixes](https://github.com/civicrm/civicrm-core/pull/9174) in 4.7.13. Any custom code relying on this quirk will need to be updated.
+
+### 4.7.11: Added generic action 'validate'
+
+A generic validate action which can be used to return an array of errors in an API call. The error values returned are `key =&gt;` value pairs with the key being the name of the field and value array containing a description message and error code. For example:
+
+```php
+    civicrm_api3('Contact', 'validate', array('action' => "create"));
+
+    { "is_error": 0,
+     "version": 3,
+     "count": 1,
+     "id": 0,
+     "values": [
+      {
+        "contact_type":
+           {
+            "message": "Mandatory key(s) missing from params array: contact_type",
+            "code": "mandatory_missing"
+           }
+       }
+     ]
+    }
+```
+
+### 4.7.0: Support for joins across multiple entities
+
+Most api "get" operations now support joining onto related entities for the filters, return values, or sort fields.
+
+### 4.7.0: REST XML format
+
+The encoding of some values in the XML-based API changed. [Changes](https://github.com/civicrm/civicrm-core/pull/6043).
+
+### 4.7.0: Permission changes
+
+-   If you have 'access CiviCRM' permissions, you can now retrieve countries: [CRM-16963](https://issues.civicrm.org/jira/browse/CRM-16963) and [CRM-16963 Changes](https://github.com/civicrm/civicrm-core/pull/6408)
+-   If you have 'edit all contacts' permissions, you can now delete relationships using the API: [CRM-15991](https://issues.civicrm.org/jira/browse/CRM-15991) and  [CRM-15991 Changes](https://github.com/civicrm/civicrm-core/pull/6378)
+-   Contact related apis (phone, email, address, im, website, relationship, case, etc.) now respect fine-grained contact ACLs instead of requiring heavy-handed permissions like "view all contacts"
+
+### 4.7.0: Searching on custom fields now works for all entity types
+
+With previous versions of the API, you could not search on custom fields of entities, except for contacts. This issue has been resolved: now you can search the custom fields of any entity type. See [CRM-16036](https://issues.civicrm.org/jira/browse/CRM-16036) and [CRM-16036 Changes](https://github.com/civicrm/civicrm-core/pull/6488). This fix involved a considerable change in the inner workings of the API, so it may cause some unexpected results. If you bump into an issue, please report it.
+
+### 4.6.7 Multi-select custom field are always returned as numerical indexed arrays
+
+In previous versions of the API, multi-select custom fields were returned either as numerical indexed arrays, either as key-value arrays, depending on the entity type the custom field set applied to. From CiviCRM 4.6.7 on, all multi-select custom fields are returned as numerical indexed arrays. See [CRM-15915](https://issues.civicrm.org/jira/browse/CRM-15915) and [CRM-15915 Changes](https://github.com/civicrm/civicrm-core/pull/6430). (This is still work in progress)
+
+### 4.6.7: Fixes for chained calls
+
+Some bugs for API chaining were fixed:
+
+-   You can chain a LocBlock call to an Event call, even if the event doesn't have a loc block: [CRM-16169](https://issues.civicrm.org/jira/browse/CRM-16168).
+-   You can chain multiple create calls that create multiple entities at once: [CRM-15815](https://issues.civicrm.org/jira/browse/CRM-15815).
+-   Chaining now works with both sequential=1 and reload=1: [CRM-15904](https://issues.civicrm.org/jira/browse/CRM-15904) 
+
+See [Pull Request](https://github.com/civicrm/civicrm-core/pull/6418).
+
+### 4.6.0: 'setvalue' api action deprecated
+
+The 'setvalue' generic api action was used to change one field of a given entity. It was problematic in that it bypassed hooks and business logic related to updating that entity, and is now deprecated. Use the 'create' action instead to update all entities by passing their id plus fields to be modified.
+
+### 4.6.0: Added 'force_rollback' option
+
+The force_rollback option allows one to simulate an API call – all the logic of the API call will run, but any changes to the databases will be rolled back (reverted).
+
+### 4.5.0: Added 'getrefcount' action
+
+API action "getrefcount" is a generic action which counts the number of references to a record. For example:
+
+-   If you called `civicrm_api3('Contact','getrefcount',array('id'=&gt;123)`, the result might tell you that there are a total of 10 references -- 1 reference in `civicrm_email.contact_id`, 2 references in `civicrm_address.contact_id`, 2 references in `civicrm_phone.contact_id`, and 5 references in `civicrm_activity_contact.contact_id`. 
+-  The activity type "Survey" is an option-value record. If you queried the refcount for that option-value, the result might list a total of  8 references -- 6 references in `civicrm_activity.activity_type_id`, 1 reference in `civicrm_survey.activity_type_id`, and 1 reference in  CiviCase XML.
+
+The implementation automatically detects the following types of
+references:
+
+-   Standard SQL foreign-keys
+-   Dynamic SQL foreign-keys which follow the pattern `entity_table+entity_id`.
+-   Quasi-SQL foreign keys which are linked to OptionValue's (via "pseudo-constants")
+
+To detect other references, one must implement `hook_civicrm_referenceCounts` or `CRM_Core_Component_Info::getReferenceCounts()`. For example, `CRM_Case_Info implements getReferenceCounts()` to count references from CiviCase XML to activity-types.
+
+### 4.5.0: Added 'getlist' action
+
+API action "getlist" is a wrapper for API action "get." It is used mainly for quicksearch and autocomplete widgets. A call to, for example: `CRM.api3('contact', 'getlist', {input: 'bob'})` will internally call contact.get and return a list of resuts formatted for use by the select2 widget or other autocomplete/search forms. It supports formatted description, icons or other images in the results, infinite scrolling or paging of search results, and context-aware searching.
+
+See [EntityRef Fields documentation](../../framework/quickform/entityref.md) for more info.
+
+### 4.4.5: Added client-side CRM.api3() wrapper
+
+`CRM.api3()` is the new api wrapper in javascript and is the recommended way to call the api from the client-side. It supplants the now deprecated `cj().crmAPI()` and `CRM.api()` functions.
+
+The new wrapper does *not* accept callback functions but instead returns a jQuery deferred object which you can attach one or more handlers to.
+
+The new wrapper supports issuing multiple api calls in a single requestto save bandwidth and server-load.
+
+### 4.4.0: 'getoptions' action accepts additional params related to context
+
+See [Pseudoconstant (option list) Reference](../../framework/pseudoconstant.md)
+
+### 4.4.0: 'getoptions' action respects 'sequential' param
+
+The 'sequential' param will cause results to be returned in a non-associative array, which is especially useful for json. Prior to 4.4, this param was ignored for the 'getoptions' action. This has now been fixed.
+
+!!! caution
+    Because api calls from the smarty context set 'sequential=1' as a default, this will produce inconsistent results from 4.3 to 4.4 if you do not explicitly set this param. 
+
+See:[CRM-13608](http://issues.civicrm.org/jira/browse/CRM-13608)
+
+### 4.4.0: 'create' action accepts 'options.reload=1'
+
+When calling the "create" action, the API returns a copy of the record. However, for many entities, the returned value does not meet expectations – for example, if a hook (like `hook_civicrm_post`) has manipulated the record in the DB, then the manipulated record will not appear the return-value. Also, any field-values with dates or NULLs may appear unusually formatted. If your application relies on the return-value being correct & consistent, then pass in 'option.reload=1', e.g.
+
+```php
+$result = civicrm_api3('Contact', 'create', array(
+  'contact_type' => 'Individual',
+  'first_name' => 'First',
+  'last_name' => 'Last',
+  'nick_name' => 'Firstie',
+  'options' => array(
+    'reload' => 1,
+  ),
+));
+```
+
+After completely creating or updating the record, the API will reload the record with "get". This ensures greater consistency but may incur a slight performance penalty.
+
+See also: [CRM/Utils/API/ReloadOptionTest.php](https://github.com/civicrm/civicrm-core/blob/master/tests/phpunit/CRM/Utils/API/ReloadOptionTest.php)
+
+### 4.4.0: 'create' and 'replace' actions accept 'options.match' or 'options.match-mandatory'
+
+When calling the "create" or "replace" action, one may wish to update an existing record. In this past, this required passing the ID. If one passes 'options.match', the API will attempt to update an existing record.
+
+The option is available in two variations, 'options.match' and 'options.match-mandatory' (which requires that a match be found – if no match is found, it raises an error).
+
+**Using "options.match" with "create"**
+```php
+// Create "Jeffrey Lebowski" with external ID "1234".
+// If a contact already exists with external ID "1234", update it.
+$result = civicrm_api3('contact', 'create', array(
+  'contact_type' => 'Individual',
+  'first_name' => 'Jeffrey',
+  'last_name' => 'Lebowski',
+  'nick_name' => 'The Dude',
+  'external_identifier' => '1234',
+  'options' => array(
+    'match' => 'external_identifier',
+  ),
+));
+```
+
+**Using "options.match" with "replace"**
+```php
+// Update contact #123 and reconcile his email addresses with the given list.
+//
+// If the contact already has an email record for "one@example.com", it will
+// be updated. (Extra metadata -- like on-hold status -- will be preserved.)
+// If not, a new email record will be inserted.
+//
+// Similarly, an email record for "two@example.com" will be updated or
+// inserted.
+//
+// Any other email records for contact #123 will be deleted.
+$result = civicrm_api3('contact', 'create', array(
+  'id' => 123,
+  'api.Email.replace' => array(
+    'values' => array(
+      array('email' => 'one@example.com', 'location_type_id' => 1),
+      array('email' => 'two@example.com', 'location_type_id' => 2),
+    ),
+    'options' => array('match' => 'email'),
+  ),
+));
+```
+See also: [CRM/Utils/API/MatchOptionTest.php](https://github.com/civicrm/civicrm-core/blob/master/tests/phpunit/CRM/Utils/API/MatchOptionTest.php)
+
+### 4.4.0: Smarty wrapper defaults to 'sequential'
+
+Because 'sequential' gives a more concise format, it has been made the default in smarty. If you do not want the sequential format, add sequential=0 to your smarty api call.
+
+### 4.3.0: New 'getoptions' action
+
+Fetch the options for a specified field e.g. `civicrm_api('contact', 'getoptions' array('field' => 'gender_id'));` returns `array(1 => 'Female', 2 => 'Male', 3 => 'Other')`
+
+See [Pseudoconstant (option list) Reference](../../framework/pseudoconstant.md)
+
+### 4.3.0: Deprecating action=update
+
+CRM-12140: The API update action was a clunky hack (get+create) to workaround the problems on the create api with an id set (mostly forcing default values). We have now have all (well, at least most of) the entities that behaves on create. We are keeping the action=update working as it was, but no longer mention it in the docs and have removed it from the api explorer as a default action
+
+### 4.3.0: Default permission changed from "access CiviCRM" to "administer CiviCRM"
+
+-   [CRM-11329](http://issues.civicrm.org/jira/browse/CRM-11329#comment-46699)
+-   This affects API functions called with `check_permissions = 1` (all AJAX, & REST calls) where the permission is not otherwise     defined
+-   **This could affect you if**\
+    1.   you use Rest / Ajax for non permissioned users or you use the `check_permissions` flag in smarty or php calls AND
+    2.   You access API functions in this way which don't have explicitly defined permissions in CRM/Core/DAO/,permissions.php (most common functions are defined)
+    3.  You use custom api via REST and have not defined the permissions for them (using the hook)
+-   See the ticket for more
+
+### 4.3.0: AJAX: cj().crmAPI() is now CRM.api()
+
+Prior to 4.3, the syntax for [AJAX](interfaces.md#AJAX) API calls was 
+
+```javascript
+cj().crmAPI('Entity', 'action', {...params...}, {
+  callBack: function(data) { ... }
+});
+```
+
+This notation is still supported in 4.3. However, the recommended notation has changed to:
+
+```javascript
+CRM.api('Entity', 'action', {...params...}, {
+  success: function(data) { ... }
+});
+```
+
+### 4.3.0: REST: user/password authentication unsupported
+
+In previous releases, REST API calls supported two forms of authentication:
+
+-   Authentication with a per-user API key (e.g. `rest.php?entity=contact&action=get&api_key=...&key=...`) 
+-   Authentication with a username/password (e.g.`rest.php?q=civicrm/login&user=...&pass=...&key=...`) and subsequent requests with a PHPSESSID (e.g. `rest.php?q=civicrm/contact/get&PHPSESSID=...&key=...`)
+
+The second form is no longer supported.
+
+### 4.3.5 / 4.2.10: Introduction of civicrm_api3 wrapper
+
+This allows the syntax
+
+```php
+try {
+  civicrm_api3('contact', 'get', array());
+  civicrm_api3('contribution', 'sendconfirmation', array('id' => 100));
+}
+catch (CiviCRM_API3_Exception $e) {
+  $error = $e->getMessage();
+}
+```
+
+## APIv3: Specific APIs (Changes)
+
+### 4.7.25: Event API. price_set_id not returned unless specified.
+
+This api now follows the standard convention of only returning extra data when requested. Specify `return: 'price_set_id'` in the params to fetch this field.
+
+### 4.7.20/4.7.13 : Extensions API Get. All Information on Extensions is returned by default
+
+When calling either the get or getsingle action for the Extension API you will now by default be returned all information on an extension rather than just id status and key - See [CRM-19414](https://issues.civicrm.org/jira/browse/CRM-19414). However the initial implementation meant that there was no ability to filter Extensions down to just retrieve either information on one extension or a specific set of fields for extensions. This has been fixed
+in [CRM-20532](https://issues.civicrm.org/jira/browse/CRM-20532) released in 4.7.20
+
+### 4.7.11: Group API: "group_type" is supported for both integer and array values
+
+When creating a new Group, the "create" API previously failed for `group_type` parameter. This is now supported for both integer and array values.
+
+-   Using Integer - `group_type => 2` will create a group with only type "Mailing List".
+-   Using arrays  - `group_type => array(1, 2)` will create a group with both "Access Control" and "Mailing List" as its types.
+
+### 4.7.0: GroupContact API
+
+Deprecated ability to use the 'create' method with multiple contacts / groups in the format `contact_id.1`, `contact_id.2` / `group_id.1`, `group_id.2` etc. This will be removed in a future version. The new approach, using arrays, is documented in the API additions section.
+
+### 4.6.0: Mailing API
+
+-   Default values now match the default values of the user-interface. For example, if `footer_id` is omitted, then the default footer     is used.
+-   When saving a mailing, the recipient list and the scheduled job will not be created by default. They will be created when a `scheduled_date` is set.
+-   The default `api.mailing_job.create: 1` has been removed.
+-   The "submit" action is akin to "create", but it requires a `scheduled_date` and works with CiviMail's advanced/optional permission model.
+-   When using advanced CiviMail workflows, the "create" and "submit" actions will enforce the additional permissions for 'create mailings', 'schedule mailings', and 'approve mailings'.
+-   If the site policy requires standard mail-merge tokens (as it should, as it does by default), then the Mailing API will enforce that requirement when scheduling the blast.
+
+### 4.6.0: Mailing Component API
+
+By default, components are now filtered on `is_active=1`. To get the full listing of components (regardless of `is_active`), specify a query value `is_active = NULL`. Make sure you use an API binding that supports NULL (e.g. `civicrm_api3` or JSON-based REST). Example:
+
+```php
+civicrm_api3('MailingComponent','get',array('is_active' =>  NULL));
+```
+
+### 4.5.0: Case API: "case_type" corresponds to machine-name
+
+When creating a new Case record, the "create" API previously accepted `case_type` using the displayable title of the case-type (e.g. "Housing Support"). Beginning in v4.5, the `case_type` should specify the internal machine-name of the case-type (e.g. `housing_support`). Submitting the displayable title will still work - but this is deprecated. For more discussion about changes to handling of case-type names, see [Check Case Type Name Consistency](https://wiki.civicrm.org/confluence/display/CRMDOC/checkCaseTypeNameConsistency).
+
+### 4.4.0: Activity API Changes
+
+`source_contact_id`  is no longer part of the activity record, it is returned by default from the new activity contact table so the change does not need to affect interactive code
+
+### 4.3.0: Deprecate Constant API
+
+Most `CRM_*_Pseudoconstant methods` (which the 'constant' api is a wrapper for) are deprecated in 4.3 and many are removed in 4.4. To future-proof your code, use the [api.getoptions](../v3/actions.md#getoptions) method instead of the constant api. See [Pseudoconstant (option list) Reference](../../framework/pseudoconstant.md)
+
+### 4.3.0: Contact get API now respects ACLS
+
+This means that contact get api now gets only the contacts for which the logged in person is permission if you set the `check_permissions` flag on the api call (it is always set for REST calls & Smarty). Note that the fields that can be returned from contact api if `check_permissions` is set are restricted to those shown by 'getfields'
+
+Sponsored by Fuzion.
+
+### 4.3.0: Contribution API creates line items
+
+If you create a contribution then a default line item will be automatically created for it according to various rules. If you wish to create the line items yourself you need to add the param `'skipLineItems' => 1`
+
+### 4.3.0: Create events from a template
+
+The event api can now clone templates similar to how the UI can do it. Add the param `template_id` and all properties of that event template (including payment processors, profiles, scheduled reminders, etc) will be added to your new event.
+
+## APIv3: Specific APIs (Additions)
+
+### 4.7.15 StateProvince API
+
+This API can be used to create, update and delete 'state/province' entries via the API. Added in CRM-19688.
+
+### 4.7.7 System.updatelogtables
+
+This api can be called to change the format of the `log_conn_id` fields to a 17 Char varchar - and to switch to using truly unique connection ids. Calling this api can also convert log tables to INNODB - using this hook [hook_civicrm_alterLogTables](../../hooks/hook_civicrm_alterLogTables.md) either in your code or with the [Extension](https://github.com/eileenmcnaughton/nz.co.fuzion.innodbtriggers/blob/master/innodbtriggers.php)
+
+Note that log table conversion can be slow which is why we are offering a conversion tool for the improved `log_conn_id` storage rather than springing it in an upgrade script
+
+### 4.7.0: EntityBatch, SavedSearch, OpenId
+
+These entities are now accessible using the api:
+
+- EntityBatch: [CRM-16842](https://issues.civicrm.org/jira/browse/CRM-16842) and [Pull Request](https://github.com/civicrm/civicrm-core/pull/6211)
+- SavedSearch: [CRM-16701](https://issues.civicrm.org/jira/browse/CRM-16701) and [Pull Request](https://github.com/civicrm/civicrm-core/pull/6059)
+- OpenId: [CRM-16517](https://issues.civicrm.org/jira/browse/CRM-16517) and [Pull Request](https://github.com/civicrm/civicrm-core/pull/5853)
+
+### 4.7.0: GroupContact API accepts array of contact_id or group_id
+
+It is now possible to add multiple contacts to one or more groups using a standard array. The 'create' method now correctly accepts an array of contact ids in the `contact_id` param, or an array of groups in the `group_id` param. This replaces the legacy functionality that was deprecated in this version.
+
+### 4.7.0: StatusPreference API
+
+The StatusPreference API controls access to the new StatusPreference entity.  It is used to read and write the values for the CiviCRM 4.7 Status Page.
+
+### 4.6.0: Attachment API
+
+The Attachment API allows reading and writing attachments. It is a successor to File API which provides a unified interface for managing 
+
+- `civicrm_file` records,
+- `civicrm_entity_file records`, and
+- file content on disk. Details (at time of writing):
+    - It supports attachments on Activity and Mailing records.
+    - Permissions derive from the permissions on the related entity. (Ex: To attach a file to a mailing, one must have permission to  create/edit mailings. To read a file from an activity, one must have  permission to read activities.) Only coarse-grained permissions are supported.
+    - It supports 1-M relations (one entity to many attachments). Theoretically, the DB schema allows M-M, but this has not been used in practice and requires more complicated DX.
+
+### 4.6.0: Mailing AB API
+
+The Mailing AB API allows creation of A/B tests.
+
+### 4.5.0: contribution_page.submit action
+
+Similar to profile.submit - this takes the values you would pass into the form and uses them for post processing. - including credit card processing, creating memberships etc. This api has mostly been used in the test suite so far so you should investigate carefully before using it. (Profile.submit is more mature)
+
+### 4.5.0: CaseType API
+
+The CaseType API allows one to create, modify, and delete case types. This includes support for setting the detailed activity/relationship configuration with the "definition" property. For examples, see `api_v3_CaseTypeTest`.
+
+### 4.4.8: FinancialType, FinancialAccount, ActivityContact API
+
+### 4.4.?: Dashboard API -- Enable developers to register new dashlets
+
+```php
+$result = civicrm_api3('dashboard', 'create', array(
+  'label' => 'New Dashlet element',
+  'name' => 'New Dashlet element',
+  'url' => 'civicrm/report/list&reset=1&compid=99&snippet=5',
+  'fullscreen_url' => 'civicrm/report/list&compid=99&reset=1&snippet=5&context=dashletFullscreen',
+));
+```
+
+### 4.4.?: DashboardContact API -- Enable developers to assign dashlets to the dashboard for particular users
+
+```php
+$result = civicrm_api3('dashboard_contact', 'create', array(
+  'contact_id' => $contact['id'],
+  'dashboard_id' => $dashresult['id'],
+  'is_active' => 1,
+));
+```
+
+### 4.4.2: ActionSchedule API (Scheduled Reminders)
+
+```php
+$activityContacts = CRM_Core_OptionGroup::values('activity_contacts', FALSE, FALSE, FALSE, NULL, 'name');
+$assigneeID = CRM_Utils_Array::key('Activity Assignees', $activityContacts);
+$targetID = CRM_Utils_Array::key('Activity Targets', $activityContacts);
+$scheduledStatus = CRM_Core_OptionGroup::getValue('activity_status', 'Scheduled', 'name');
+$mappingId = CRM_Core_DAO::getFieldValue('CRM_Core_DAO_ActionMapping', 'activity_type', 'id', 'entity_value');
+$activityTypeId = CRM_Core_OptionGroup::getValue('activity_type', "Meeting", 'name');
+$result = civicrm_api3('dashboard', 'create', array(
+  'title' => "simpleActionSchedule",
+  'recipient' => $assigneeID,
+  'limit_to' => 1,
+  'entity_value' => $activityTypeId,
+  'entity_status' => $scheduledStatus,
+  'is_active' => 1,
+  'record_activity' => 1,
+  'mapping_id' => $mappingId,
+));
+```
+
+### 4.4.0 Profile submit & getfields api
+
+Using these api along with get you can build your own profile form prefilled with a contact id and use the params from it to submit as if  you were using the built in profile. The prefilling on `cid=0` pages use the profile.get with `contact_id`
+
+### 4.4.0: Soft Credits API
+
+Civi 4.4 has a MIH to support multiple soft credits per contact. The soft credit API supports the new functions. [CRM-12496](http://issues.civicrm.org/jira/browse/CRM-12496)
+
+### 4.4.0: Mailing Contact API
+
+[CRM-12357](http://issues.civicrm.org/jira/browse/CRM-12357)
+
+### 4.4.0: Report Instance API
+
+[CRM-12877](http://issues.civicrm.org/jira/browse/CRM-12877)
+
+### 4.3.4 / 4.2 LTS Contribution.completetransaction action (like an IPN)
+
+This api takes a pending contribution and completes it, updating related entities like memberships and sending out emails as required. Some IPN call this function in their handlePaymentNotification function (as soon as they have ascertained a successful payment)
+
+### 4.3.0: Location Type API
+
+Big thanks to Jon Goldberg  [CRM-11206](http://issues.civicrm.org/jira/browse/CRM-11206)
+
+### 4.3.0: Mailing API
+
+Functions to create new CiviMails contributed by Chris Burgess of Giant Robot.
+
+### 4.3.0 / 4.2.10: Setting API
+
+Settings can be set / retrieved / reverted to defaults for single or mulitple domains using the setting api. There is also the ability to define default settings e.g country - specific ones by hook (Try the civiconfigure extension for more on that)
+
+### 4.3.0: Job API
+
+Schedule cron tasks by creating records with the "Job" API.
+
+### 4.3.0: Payment Processor API
+
+Implements basic CRUD functionality for payment processors.
+
+### 4.3.0: LocBlock API
+
+Although location blocks are no longer used by CiviCRM contacts, they are currently still used for events. So the main purpose of this api is to allow you to CRUD the address, emails and phones associated with an event.
+
+## Object-Oriented APIs
+
+This section doesn't document changes to APIv3 per se – rather, it documents changes to public-facing PHP classes. For example, when a developer writes a custom report or custom search, he typically extends a public-facing PHP class, and any changes to that class should be clearly communicated. 
+
+### 4.3.0: CRM_Contact_Form_Search_Interface::all
+
+The all method has a new parameter and a custom search written for 4.2 needs to be changed to have a new $justIDs = FALSE param. The new signature for all:
+
+```php
+function all($offset = 0, $rowcount = 0, $sort = NULL,$includeContactIDs = FALSE, $justIDs = FALSE)
+```
+
+You need to upgrade civix as well so it generates this new code for a custom search
+
+### 4.6.0: CRM_Contact_Form_Search_Interface-&gt;buildTaskList
+
+Classes which implement this interface must implement a new method called buildTaskList. This method is responsible for building the list of actions (e.g., Add to Group) that may be performed on set of search results. It differs
+from [hook_civicrm_searchTasks](../../hooks/hook_civicrm_searchTasks.md) in that the hook allows a developer to specify tasks by entity (e.g., Contact, Event, etc.) whereas buildTaskList provides the ability to target a specific form. The new method takes a `CRM_Core_Form_Search` object as an argument and should return an array. Dump `CRM_Core_Form_Search()->_taskList` to learn about the format of the array. The array returned by buildTaskList will completely replace the task list.
+
+Aside from the community-maintained custom searches in `CRM/Contact/Form/Search/Custom/`, this change does not affect CiviCRM core. Custom searches which extend `CRM_Contact_Form_Search_Custom_Base` (as do those built on civix) will not be affected, as the method is implemented there.
+
+See [CRM-15965](https://issues.civicrm.org/jira/browse/CRM-15965) for more information.
+
+## Other
+
+### 4.7.0: CRM_Core_Config: Property loading
+
+In previous versions, the properties in `CRM_Core_Config` were loaded from a mix of sources, most notably a SQL field (`civicrm_domain.config_backend`). The `config_backend` contained a mix of canonical settings and caches. For any given property, it was very difficult to trace the lifecycle (e.g. to identify where the property was canonically stored, how it was filtered, or how it could be changed).
+
+In v4.7+, all persistent settings should now be stored canonically in the table *civicrm_setting*, and caches should be stored using a cache service. These are not stored in *civicrm_domain.config_backend*.
+
+To provide backward compatibility, `CRM_Core_Config` defines properties with the magic methods, `__get()`  and `__set()`. To trace a property (and determine where it's truly stored), examine `Core_Config_MagicMerge::getPropertyMap()`.
+
+Most downstream code should work with `CRM_Core_Config` properties the same way as before, but there are a couple caveats:
+
+-   If a property's value is an array, you cannot directly modify the array-elements (e.g. "`$config->foo['bar'] = 123;`); doing so will produce a PHP warning. Instead, you can replace the array `$config->foo = $config->foo + array('bar' => 123);`. (There were no examples of this in the core codebase, but there was one example in the core test suite.)
+-   A handful of properties were removed because they appeared to be unused, misleading, or redundant.
+-   `enableComponentIDs`, `formKeyDisable`, `gettextCodeset`, `gettextDomain`, `gettextCodeset`, `gettextDomain`, `gettextResourceDir`, `groupTree`, `importDataSourceDir`, `localeCustomStrings`, `mailerPeriod`, `mailerSpoolLimit`, `mapGeoCoding`, `maxImportFileSize`, `maxLocationBlocks`, `oldInputStyle`, `pluginsDir`, `revampPages`, `smartyDir`, `sqlDir`
+-   Attempting to access an unknown/undefined property will now trigger an error.
+
+See also: [CRM-16373](https://issues.civicrm.org/jira/browse/CRM-16373)
+
+### 4.7.0: Global $civicrm_setting: Multiple changes
+
+The global variable `$civicrm_setting` is used to [override CiviCRM settings](https://wiki.civicrm.org/confluence/display/CRMDOC/Override+CiviCRM+Settings). It has been changed:
+
+- In previous versions, settings were indexed by group name (e.g. `Search Preferences`). In v4.7+, settings should be indexed by entity name (e.g. `domain` or `contact`). For backward compatibility, most group names are treated as an alias for `domain` or `contact`.
+  ```php
+  // Old/Deprecated/Verbose. Compatible with v4.1+.
+  $civicrm_setting['Search Preferences']['search_autocomplete_count'] = 10;
+  $civicrm_setting['CiviCRM Preferences']['remote_profile_submissions'] = FALSE;
+
+  // New/Preferred/Simplified. Compatible with v4.7+.
+  $civicrm_setting['domain']['search_autocomplete_count'] = 10;
+  $civicrm_setting['domain']['remote_profile_submissions'] = FALSE;
+  ```
+- `$civicrm_setting` is usually modified within the file `civicrm.settings.php`, but it can be modified at runtime (e.g. in  a hook). *If you modify it at runtime*, then you must also call `useMandatory()` to assimilate the changes. Examples for v4.6 and  v4.7 are compared below.
+   ```php
+   // Ex: Compatible with v4.6 or older (minimalist)
+   function example_hook() {
+     global $civicrm_setting;
+     $civicrm_setting['Search Preferences']['search_autocomplete_count'] = 10;
+   }
+
+   // Ex: Compatible with v4.7 or newer (minimalist)
+   function example_hook() {
+     global $civicrm_setting;
+     $civicrm_setting['domain']['search_autocomplete_count'] = 10;
+     Civi::service('settings_manager')->useMandatory();
+   }
+
+   // Ex: Compatible with both v4.6 and v4.7
+   function example_hook() {
+     global $civicrm_setting;
+     $civicrm_setting['Search Preferences']['search_autocomplete_count'] = 10;
+     if (version_compare('>=', CRM_Utils_System::version(), '4.7.alpha1')) {
+       Civi::service('settings_manager')->useMandatory();
+     }
+   }
+   ```
+
+See also: [CRM-16373](https://issues.civicrm.org/jira/browse/CRM-16373).
+
+### 4.7.0: bin: Removed deprecated scripts
+
+Earlier versions of CiviCRM included a number of standalone scripts which could be called using `wget` and `cron`. In Civi v4.1, an API-based job-scheduler was introduced, and these cron scripts moved into APIv3 (`Job.process_mailing`, `Job.process_membership`, etc). Some scripts were left in the "bin/deprecated" folder, but these have now been removed in v4.7.
+
+### 4.6.alpha2: CRM_Core_Payment: Object construction
+
+In prior versions, payment processors followed this practice:
+
+-   (Mandatory) Implement `public static function &singleton($mode, &$paymentProcessor, &$paymentForm = NULL, $force = FALSE)`
+-   (Conventional) Implement `public function __construct($mode, &$paymentProcessor)`
+
+In v4.6+, the singleton() has been replaced by a centralized manager (Civi\Payment\System). Individual payment processors no longer require their own singletons. However, the constructor is mandatory:
+
+-   (Optional - for backward compatibility) Implement `public static function &singleton($mode, &$paymentProcessor, &$paymentForm = NULL, $force = FALSE)`
+-   (Mandatory) Implement `public function __construct($mode &$paymentProcessor)`
+
+See also: [Pull Request](https://github.com/civicrm/civicrm-core/pull/4865)
+
+### 4.6.alpha1: CRM_Core_Transaction
+
+- `CRM_Core_Transaction` has traditionally used a reference-counting mechanism to combine multiple pieces of business-logic into a single transaction. In 4.6, this remains the default behavior, but  one can also use nested transactions (by passing `$nested=TRUE` to the constructor). Any work done in the nested transaction can be rolled back without affecting the overall transaction.
+- Prior to 4.6, the idiom for managing transactions was to call `$tx = new CRM_Core_Transaction()` and rely on the destructor to cleanup the transaction (e.g. issue the COMMIT/ROLLBACK). Unfortunately, it can be cumbersome to correctly apply this idiom when handling exceptions generated by non-Civi classes. 4.6 introduces a safer notation: `CRM_Core_Transaction::create()->run(function($tx){});` which automatically rolls back in case of an exception.
+
+For more details, see [Transaction Reference](../../framework/transactions.md).
+
+### 4.5.3: AJAX, Regions, and Resources
+
+CiviCRM 4.2+ allowed developers to inject content on a web page using the [Region](../../framework/region.md) and [Resource](../../framework/resources.md) APIs. CiviCRM 4.5+ introduced broad changes to the page-loading process which cause many pages to load in-situ as "snippets". This significantly improved perceived load times but caused some regressions on customized backend forms which relied on Region or Resource APIs. v4.5.3 introduces the following changes:
+
+-   The `page-header`, `page-body`, and `page-footer` regions will all be processed on normal (full, standalone) pages as well as snippets (embedded AJAX pages).
+-   The `html-header` region is only processed on normal-pages.
+-   The `ajax-snippet` region is only processed on snippet-pages.
+-   Settings exported via Resource API (`CRM_Core_Resources::addSetting()`) will be communicated in both normal-pages and snippet-pages. The settings on the  snippet-page will merge with the settings on the normal-page. Merges are conducted deeply/recursively.
+
+### 4.5.0: CiviCase: Changes in XML
+
+1.  CiviCase XML content may be loaded from the database (`civicrm_case_type.definition`) or from a file (as in previous versions). Database content will take precedence over file content.
+2.  CiviCase XML supports additional tags:
+    1. A **&lt;CaseType&gt;** may set **&lt;forkable&gt;0&lt;/forkable&gt;**. Use this if you want  to (a) store XML in a file **and** (b) prohibit editing in the GUI See also: [CRM-15097](https://issues.civicrm.org/jira/browse/CRM-15097)
+    2. An **&lt;ActivitySet&gt;** may set **&lt;sequence&gt;true&lt;/sequence&gt;** to indicate that  activities are performed in a linear, back-to-back fashion. See  also: [CRM-14727](https://issues.civicrm.org/jira/browse/CRM-14727)
+    3.(FIXME: In 4.5.beta6, the two tags have different representations of boolean. In the next release, use "true" or  "false" for both.)
+
+3.  If a CiviCase XML file references an unknown activity-type or relationship-type, then it will be auto-created as a ManagedEntity. Moreover, if the XML changes or disappears, and if there are no records which rely on the activity-type or relationship-type, then it will be auto-removed. ManagedEntities are reconciled (created/preserved/deleted) when editing Casetypes via GUI, during extension install, and during other system flushes.
+4.  When using CiviCase XML files, the file-name and machine-name (`civicrm_case_type.name`) **should**match. Admins  may occasionally see a warning if these are mismatched.
+    1.  See also: [checkCaseTypeNameConsistency](https://wiki.civicrm.org/confluence/display/CRMDOC/checkCaseTypeNameConsistency)
+    2.  The example CiviCase XML files have been renamed:
+    
+        | Case Type (Title)| Case Type (Name) | Old Filename | New Filename |
+        | --- | --- | --- | --- |
+        | Housing Support | `housing_support` | `HousingSupport.xml` | `housing_support.xml` |
+        | Adult Day Care Referral | `adult_day_care_referral` | `AdultDayCareReferral.xml` | `adult_day_care_referral.xml` |
+
+### 4.4.6, 4.2.17: Profiles: Removed hidden fields
+
+Profile forms previously included hidden fields (`post_URL`, `cancel_URL`, and `add_to_group_id`). If you have customizations which rely on manipulating these hidden fields (e.g. by embedding a profile on a third-party site using a customized HTML snippet), then those customizations may break. However, you may still control the values of `post_URL`, `cancel_URL`, and `add_to_group_id` by configuring the profile's advanced settings. See: [CRM-14856](https://issues.civicrm.org/jira/browse/CRM-14856).

docs/api/v3/custom-data.md

+# APIv3 and Custom Data
+
+!!! warning "APIv3 Deprecation"
+    API version 3 is now deprecated. [Version 4](../v4/custom-data.md) is recommended.
+
+Custom data attached to entities is referenced by `custom_N` where `N` is the unique numerical ID for the custom data field.
+
+To set a custom field, or find entities with custom fields of a particular value, you typically use a parameter like this:
+
+```php
+$params['custom_N'] = 'value';
+```
+
+To return custom data for an entity, especially when using the CustomValue API, you typically pass a param like the following:
+
+```php
+$params['return.custom_N'] = 1;
+```
+
+*or (depending on which API entity you are querying)*
+
+```php
+$params['return'] = 'custom_N';
+```
+
+*or*
+
+```php
+$params['return'] = 'custom_N,custom_O,custom_P';
+```
+
+For setting custom date fields, (ie CustomValue create), date format is `YmdHis`, for example: `20050425000000`.
+
+This is just a brief introduction; each API may have different requirements and allow different formats for accessing the custom data. See the [API function documentation](../index.md) and also read the comments and documentation in each API php file (under civicrm/CRM/api/v3 in your CiviCRM installation) for exact details,
+which vary for each API entity and function.
+
+## Custom Value get
+
+If developers want to get all custom data related to a particular entity. The best method is to do a `CustomValue.get` API Call. 
+
+```php
+$result = civicrm_api3('CustomValue', 'get', array('entity_id' => 1));
+```
+
+A sample output would be like the following
+
+```php 
+{
+	"is_error":0,
+	"undefined_fields":["return_child:child_name"],
+	"version":3,
+	"count":1,
+	"id":2,
+	"values":[
+       {
+         "entity_id":"1",
+         "latest":"Bam Bam", 
+         "id":"2",
+         "308":"Pebbles Flintstone",
+         "309":"Bam Bam"
+ } 
+] }
+```
+
+For entities other than the Contact Entity you can use an alternate notation to the `custom_n` to specify the custom fields you wish to return. You can use `custom_group_name:custom_field_name`. Read carefully the documentation and parameters in `CustomValue.php` for more alternatives and details.
+
+!!! note 
+    When retrieving custom data for contact entity, it will only return one value in the case of a multiple custom group set whereas for other entities (e.g. Address, or using the `CustomValue.get` API) you will get all custom data records that relate to the relevant entity
+
+The CustomValue Entity implicitly determines what the `entity_table` variable should be when it is not supplied. If you find that the implicitly is not working out exactly, then specify the `entity_table` key.
+
+When setting the value of custom data that is of type checkbox or multivalue it is important to note that the options need to be passed in as an array. For example, if you want to set options `a` and `c` of the custom field with the ID `2` on Contact `123` you should do the following
+
+```php
+$result = civicrm_api3(
+  'CustomValue',
+  'create', 
+  array('entity_id' => 123, 'custom_2' => array('a', 'c'))
+);
+```

docs/api/v3/examples.md

+# APIv3 Examples
+
+!!! warning "APIv3 Deprecation"
+    API version 3 is now deprecated. [Version 4](../v4/usage.md) is recommended.
+
+All the APIv3 Examples are generated through Tests in the CodeBase and are auto-generated from those tests so we can be certain of the code that is given. 
+
+## Location of Examples
+
+The most current examples can be found in CiviCRM's GitHub Repo on the [Master Branch](https://github.com/civicrm/civicrm-core/tree/master/api/v3/examples). When you install CiviCRM the Examples that come with the particular version of CiviCRM you have installed can be found in `<civicrm_root>/api/v3/examples`. You will also be able to view them through the [API Explorer](../index.md#api-explorer) by clicking on the **Examples** tab in the Explorer.
+
+## Creating a New Example
+
+If you find that there is an API call or similar or perhaps a parameter for an API call that you feel is missing an example for that would be useful to the community, you can create a new example in the following way:
+
+1. Find the relevant API test file e.g. `tests/phpunit/api/v3/MembershipTest.php`
+2. Write your unit test with the API call that you want to create an Example of, however rather than using `$this->callAPISuccess` use `$this->callAPIAndDocument`. The Call API and Document function should be called similar to the following
+
+    ```php
+    $description = "This demonstrates setting a custom field through the API.";
+    $result = $this->callAPIAndDocument($this->_entity, 'create', $params, __FUNCTION__, __FILE__, $description);
+    ```
+
+3. Find in `tests/phpunit/CiviTest/CiviUnitTestCase.php` Find the function `documentMe` and comment out the if (defined) statement.
+4. Run the test suite locally for that test e.g. `./tools/scripts/phpunit 'api_v3_MembershipTest'`.
+5. Commit results including changes in the Examples dir and open a pull request.