Skip to content
Snippets Groups Projects
Commit 69240354 authored by Sean Madsen's avatar Sean Madsen Committed by GitHub
Browse files

Merge pull request #280 from seamuslee001/master 

Fix up urls
parents e960c447 6b14c957
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Showing
with 16 additions and 16 deletions
docs/api/changes.md
+ 16
− 16
View file @ 69240354
......@@ -111,7 +111,7 @@ The new wrapper supports issuing multiple api calls in a single requestto save b
### 4.4.0: 'getoptions' action accepts additional params related to context
See [Pseudoconstant (option list) Reference](/confluence/display/CRMDOC43/Pseudoconstant+%28option+list%29+Reference)
See [Pseudoconstant (option list) Reference](https://wiki.civicrm.org/confluence/display/CRMDOC43/Pseudoconstant+%28option+list%29+Reference)
### 4.4.0: 'getoptions' action respects 'sequential' param
......@@ -197,7 +197,7 @@ Because 'sequential' gives a more concise format, it has been made the default i
Fetch the options for a specified field e.g. `civicrm_api('contact', 'getoptions' array('field' => 'gender_id'));` returns `array(1 => 'Female', 2 => 'Male', 3 => 'Transgender')`
See [Pseudoconstant (option list) Reference](/confluence/display/CRMDOC/Pseudoconstant+%28option+list%29+Reference)
See [Pseudoconstant (option list) Reference](https://wiki.civicrm.org/confluence/display/CRMDOC/Pseudoconstant+%28option+list%29+Reference)
### 4.3.0: Deprecating action=update
......@@ -215,7 +215,7 @@ CRM-12140: The API update action was a clunky hack (get+create) to workaround th
### 4.3.0: AJAX: cj().crmAPI() is now CRM.api()
Prior to 4.3, the syntax for [AJAX](/api/interfaces#AJAX) API calls was
Prior to 4.3, the syntax for [AJAX](/api/interfaces.md#AJAX) API calls was
```javascript
cj().crmAPI('Entity', 'action', {...params...}, {
......@@ -291,7 +291,7 @@ 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](/confluence/display/CRMDOC/checkCaseTypeNameConsistency).
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
......@@ -299,7 +299,7 @@ When creating a new Case record, the "create" API previously accepted `case_type
### 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](/api/changes#getOptions) method instead of the constant api. See [Pseudoconstant (option list) Reference](/confluence/display/CRMDOC/Pseudoconstant+%28option+list%29+Reference)
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](/api/actions.md#getoptions) method instead of the constant api. See [Pseudoconstant (option list) Reference](https://wiki.civicrm.org/confluence/display/CRMDOC/Pseudoconstant+%28option+list%29+Reference)
### 4.3.0: Contact get API now respects ACLS
......@@ -323,7 +323,7 @@ This API can be used to create, update and delete 'state/province' entries via t
### 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](/hook/hook_civicrm_alterLogTables) either in your code or with the [Extension](https://github.com/eileenmcnaughton/nz.co.fuzion.innodbtriggers/blob/master/innodbtriggers.php)
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
......@@ -471,7 +471,7 @@ You need to upgrade civix as well so it generates this new code for a custom sea
### 4.6.0: CRM_Contact_Form_Search_Interface->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](/hook/hook_civicrm_searchTasks) 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.
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.
......@@ -479,7 +479,7 @@ See [CRM-15965](https://issues.civicrm.org/jira/browse/CRM-15965) for more infor
## Hooks
This section doesn't document changes to APIv3 per se – rather, it documents changes to the the [Hook](/confluence/display/CRMDOC43/Hook+Reference) interfaces.
This section doesn't document changes to APIv3 per se – rather, it documents changes to the the [Hook](/hooks/index.md) interfaces.
### 4.7.14 hook_civicrm_pre & hook_civicrm_post supports CustomField
......@@ -499,15 +499,15 @@ The deprecated enableDisablehook was not reliably invoked every time an entity
### 4.5.0: hook_civicrm_referenceCounts
The new API call "getrefcount" allows one to ask about references to a given record. Using [hook_civicrm_referenceCounts](/hook/hook_civicrm_referenceCounts), a third-party developer can modify the reference-count.
The new API call "getrefcount" allows one to ask about references to a given record. Using [hook_civicrm_referenceCounts](/hooks/hook_civicrm_referenceCounts.md), a third-party developer can modify the reference-count.
### 4.4.0: Add hooks for profile forms
Added hooks for
- "civicrm/profile/view" [hook_civicrm_viewProfile](/hook/hook_civicrm_viewProfile),
- "civicrm/profile" [hook_civicrm_searchProfile](/hook/hook_civicrm_searchProfile),
- "civicrm/profile/edit" or "civicrm/profile/create" [hook_civicrm_buildProfile](/hook/hook_civicrm_buildProfile),[hook_civicrm_validateProfile](/hook/hook_civicrm_validateProfile), [hook_civicrm_processProfile](/hook/hook_civicrm_processProfile)).
- "civicrm/profile/view" [hook_civicrm_viewProfile](/hooks/hook_civicrm_viewProfile.md),
- "civicrm/profile" [hook_civicrm_searchProfile](/hooks/hook_civicrm_searchProfile.md),
- "civicrm/profile/edit" or "civicrm/profile/create" [hook_civicrm_buildProfile](/hooks/hook_civicrm_buildProfile.md),[hook_civicrm_validateProfile](/hooks/hook_civicrm_validateProfile.md), [hook_civicrm_processProfile](/hooks/hook_civicrm_processProfile.md)).
See also: [CRM-12865](http://issues.civicrm.org/jira/browse/CRM-12865)
......@@ -540,7 +540,7 @@ 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](/confluence/display/CRMDOC/Override+CiviCRM+Settings). It has been changed:
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 ("domain" or "contact"). For backward compatibility, most group names are treated as an alias for "domain" or "contact".
- Old/Deprecated: `$civicrm_setting['Search Preferences']['search_autocomplete_count'] = 10;`
......@@ -598,11 +598,11 @@ See also: [Pull Request](https://github.com/civicrm/civicrm-core/pull/4865)
- `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](/confluence/display/CRMDOC/Transaction+Reference).
For more details, see [Transaction Reference](https://wiki.civicrm.org/confluence/display/CRMDOC/Transaction+Reference).
### 4.5.3: AJAX, Regions, and Resources
CiviCRM 4.2+ allowed developers to inject content on a web page using the [Region](/framework/Region/) and [Resource](/framework/Resource) 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:
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.
......@@ -619,7 +619,7 @@ CiviCRM 4.2+ allowed developers to inject content on a web page using the [Regio
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](/confluence/display/CRMDOC/checkCaseTypeNameConsistency)
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 |
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment