Last link cleanup(??) and removing now-unused files

content/_snippets/data_types/public_key.md

@@ -2,7 +2,7 @@ The XRP Ledger uses public keys to verify cryptographic signatures in several pl
 
 * To authorize transactions, a public key is attached to the transaction. The public key must be mathematically associated with the sending XRP Ledger address or the sender's regular key address.
 * To secure peer-to-peer communications between `rippled` servers. This uses a "node public key" that the server generates randomly when it starts with an empty database.
-* To sign validation votes as part of the consensus process. This uses a "validator public key" that the server operator [defines in the config file](tutorial-rippled-setup.html#validator-setup).
+* To sign validation votes as part of the consensus process. This uses a "validator public key" that the server operator [defines in the config file](run-rippled-as-a-validator.html).
 
 Validator public keys and node public keys use the exact same format.
 

content/concepts/complex-payment-types/checks.md

@@ -108,4 +108,7 @@ For more information about related features, see:
 * [Payment Channels Tutorial](use-payment-channels.html)
 
 
-{% include '_snippets/tx-type-links.md' %}
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}

content/concepts/complex-payment-types/escrow.md

@@ -41,7 +41,7 @@ Escrow provides strong guarantees that are best suited for high-value, low-quant
 
 ## Availability of Escrow
 
-Conditional payments have been enabled by the ["Escrow" Amendment](reference-amendments.html#escrow) to the XRP Ledger Consensus Protocol since 2017-03-31. A previous version of the same functionality was available on the [Ripple Test Net](https://ripple.com/build/ripple-test-net/) by the name "Suspended Payments" (SusPay) in 2016.
+Conditional payments have been enabled by the ["Escrow" Amendment](known-amendments.html#escrow) to the XRP Ledger Consensus Protocol since 2017-03-31. A previous version of the same functionality was available on the [Ripple Test Net](https://ripple.com/build/ripple-test-net/) by the name "Suspended Payments" (SusPay) in 2016.
 
 When testing in [stand-alone mode](stand-alone-mode.html), you can force the Escrow feature to be enabled locally regardless of the amendment status. Add the following stanza to your `rippled.cfg`:
 
@@ -115,8 +115,7 @@ For more information on Interledger and how conditional transfers enable secure
 
 For more information on Ripple's 55-Billion XRP Lockup, see [Ripple's Insights Blog](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/).
 
-<!--{# reference link definitions #}-->
+<!--{# common link defs #}-->
-[Interledger Protocol]: https://interledger.org/
+{% include '_snippets/rippled-api-links.md' %}			
-[crypto-condition]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-03
+{% include '_snippets/tx-type-links.md' %}			
-[crypto-conditions]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-03
+{% include '_snippets/rippled_versions.md' %}
-{% include '_snippets/tx-type-links.md' %}

content/concepts/consensus-network/amendments.md

@@ -232,6 +232,7 @@ TrustSetAuth
 ```
 
 
-
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
 {% include '_snippets/rippled_versions.md' %}
-{% include '_snippets/tx-type-links.md' %}

content/concepts/introduction/xrp-ledger-overview.md

@@ -71,7 +71,7 @@ As an entity that is obligated to hold large amounts of XRP for the long term, R
 
 Cryptography is one of the hardest parts of any distributed system, and a mistake can lead to money stolen by malicious actors anywhere in the world. The XRP Ledger uses industry-standard schemes for signing and verifying transactions, algorithms that have successfully protected hundreds of billions of US dollars' worth of value for many years. The XRP Ledger also layers multi-signing functionality so you can use multi-factor authorization or split keys across multiple people as a backup, and provides new algorithms with a path to migrate the keys you use if a breakthrough in cryptography makes the old algorithms obsolete.
 
-For more information, see [Cryptographic Keys](cryptographic-keys.html) and [Multi-Signing](#multi-signing).
+For more information, see [Cryptographic Keys](cryptographic-keys.html) and [Multi-Signing](multi-signing.html).
 
 
 ## Modern Features for Smart Contracts

content/concepts/issued-currencies/authorized-trust-lines.md

@@ -48,6 +48,7 @@ POST http://localhost:5005/
 ```
 
 {% include '_snippets/secret-key-warning.md' %}
+<!--{#_ #}-->
 
 ## Checking Whether an Account Has RequireAuth Enabled
 
@@ -89,6 +90,7 @@ POST http://localhost:8088/
 ```
 
 {% include '_snippets/secret-key-warning.md' %}
+<!--{#_ #}-->
 
 ## Checking Whether Trust Lines Are Authorized
 
@@ -96,4 +98,7 @@ To see whether a trust line has been authorized, use the [account_lines method][
 
 In the response's `result.lines` array, find the object whose `currency` field indicates that it represents a trust line for the currency you want. If that object has a `peer_authorized` field with the value `true`, then the issuer (the address you used as the request's `peer` field) has authorized the trust line.
 
-{% include '_snippets/tx-type-links.md' %}
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}

content/concepts/issued-currencies/freezes.md

@@ -407,4 +407,9 @@ Example JavaScript (ECMAScript 6) code to check whether an address has Global Fr
 # See Also
 
 * [GB-2014-02 New Feature: Balance Freeze](https://ripple.com/files/GB-2014-02.pdf)
-* [Freeze Code Samples](https://github.com/ripple/ripple-dev-portal/tree/master/content/code_samples/freeze)
+* [Freeze Code Samples](https://github.com/ripple/ripple-dev-portal/tree/master/content/_code-samples/freeze)
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}

content/concepts/issued-currencies/paths.md

@@ -92,3 +92,8 @@ The `type` field, used for the binary serialization of a path set, is actually c
 | 0x01        | 1               | A change of address (rippling): the `account` field is present. |
 | 0x10        | 16              | A change of currency: the `currency` field is present. |
 | 0x20        | 32              | A change of issuer: the `issuer` field is present. |
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}

content/concepts/issued-currencies/transfer-fees.md

@@ -45,6 +45,11 @@ You can check an account's `transferRate` with the [getSettings method](rippleap
 
 In `rippled`'s JSON-RPC and WebSocket APIs, the transfer fee is specified in the `TransferRate` field, as an integer which represents the amount you must send for the recipient to get 1 billion units of the same currency. A `TransferRate` of `1005000000` is equivalent to a transfer fee of 0.5%. By default, the `TransferRate` is set to no fee. The value of `TransferRate` cannot be set to less than `1000000000` ("0%" fee) or more than `2000000000` (a "100%" fee). The value `0` is special case for no fee, equivalent to `1000000000`.
 
-A financial institution can submit an [AccountSet transaction](accountset.html) from its [issuing address][] to change the `TransferRate` for its issuances.
+A financial institution can submit an [AccountSet transaction][] from its [issuing address][] to change the `TransferRate` for its issuances.
 
 You can check an account's `TransferRate` with the [account_info method][]. If the `TransferRate` is omitted, then that indicates no fee.
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}

content/concepts/payment-system-basics/accounts/accounts.md

@@ -93,7 +93,7 @@ The following diagram shows the relationship between keys and addresses:
 
 ![Passphrase → Secret Key → Public Key + Type Prefix → Account ID + Checksum → Address](img/key-address-rels.png)
 
-The formula for calculating an XRP Ledger address is as follows. For the complete example code, see [`encode_address.js`](https://github.com/ripple/ripple-dev-portal/blob/master/content/code_samples/address_encoding/encode_address.js).
+The formula for calculating an XRP Ledger address is as follows. For the complete example code, see [`encode_address.js`](https://github.com/ripple/ripple-dev-portal/blob/master/content/_code-samples/address_encoding/encode_address.js).
 
 1. Import required algorithms: SHA-256, RIPEMD160, and base58. Set the dictionary for base58.
 
@@ -135,6 +135,7 @@ The formula for calculating an XRP Ledger address is as follows. For the complet
         console.log(address);
         // rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN
 
-<!--{# Reference link definitions #}-->
+<!--{# common link defs #}-->
-
+{% include '_snippets/rippled-api-links.md' %}			
-{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}

content/concepts/payment-system-basics/accounts/cryptographic-keys.md

@@ -114,3 +114,8 @@ The supported types of key pairs can be used interchangeably throughout the XRP
 ### Future Algorithms
 
 In the future, Ripple expects to add new cryptographic signing algorithms to the XRP Ledger to keep up with developments in cryptography. For example, if it seems that quantum computers using [Shor's algorithm](https://en.wikipedia.org/wiki/Shor's_algorithm) (or something similar) will soon be practical enough to break elliptic curve cryptography, Ripple can add a cryptographic signing algorithm that isn't easily broken. As of early 2018, such "quantum-resistant" signing algorithms are relatively impractical and quantum computers are even more impractical, so Ripple has no immediate plans to add any specific algorithms.
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}

content/concepts/payment-system-basics/accounts/depositauth.md

@@ -42,6 +42,7 @@ An account with Deposit Authorization enabled:x
 The following table summarizes whether a transaction type can deposit money with DepositAuth enabled or disabled:
 
 {% include '_snippets/depositauth-semantics-table.html' %}
+<!--{#_ #}-->
 
 
 ## Enabling or Disabling Deposit Authorization
@@ -61,4 +62,7 @@ If the result of the `Flags` value bitwise-AND the `lsfDepositAuth` flag value (
 - The `RequireDest` flag indicates that an account can only receive currency amounts if the sending transaction specifies a [Destination Tag](become-an-xrp-ledger-gateway.html#source-and-destination-tags). This protects users from forgetting to indicate the purpose of a payment, but does not protect recipients from unknown senders, who can make up arbitrary destination tags.
 - [Partial Payments](partial-payments.html) provide a way for accounts to return unwanted payments while subtracting [transfer fees](transfer-fees.html) and exchange rates from the amount delivered instead of adding them to the amount sent.
 
-{% include '_snippets/tx-type-links.md' %}
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}

content/concepts/payment-system-basics/transaction-basics/transaction-cost.md

@@ -178,4 +178,7 @@ When the [FeeEscalation amendment](known-amendments.html#feeescalation) is enabl
 
 The XRP Ledger has a mechanism for changing the minimum transaction cost to account for long-term changes in the value of XRP. Any changes have to be approved by the consensus process. See [Fee Voting](fee-voting.html) for more information.
 
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
 {% include '_snippets/rippled_versions.md' %}

content/concepts/the-rippled-server/clustering.md

@@ -21,3 +21,8 @@ To enable clustering, change the following sections of your [config file](https:
 2. Generate a unique seed (using the [validation_create method][]) for each of your servers, and configure it under the `[node_seed]` section. The `rippled` server uses this key to sign its messages to other servers in the peer-to-peer network.
 
 3. Add each node's peer-communication public key (generated in step 2) to the `[cluster_nodes]` section of each of your other servers' config files.
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}

content/concepts/the-rippled-server/peer-protocol.md

@@ -6,7 +6,7 @@ Servers in the XRP Ledger communicate to each other using the XRP Ledger peer pr
 
 To participate in the XRP Ledger, `rippled` servers connects to arbitrary peers using the peer protocol. (All such peers are treated as untrusted, unless they are [clustered](clustering.html) with the current server.)
 
-Ideally, the server should be able to send _and_ receive connections on the peer port. You should forward the port used for the peer protocol through your firewall to the `rippled` server. The [default `rippled` configuration file](https://github.com/ripple/rippled/blob/release/doc/rippled-example.cfg) listens for incoming peer protocol connections on port 51235 on all network interfaces. You can change the port used by editing the appropriate stanza in your `rippled.cfg` file.
+Ideally, the server should be able to send _and_ receive connections on the peer port. You should forward the port used for the peer protocol through your firewall to the `rippled` server. The [default `rippled` configuration file](https://github.com/ripple/rippled/blob/master/doc/rippled-example.cfg) listens for incoming peer protocol connections on port 51235 on all network interfaces. You can change the port used by editing the appropriate stanza in your `rippled.cfg` file.
 
 Example:
 

content/concepts/the-rippled-server/the-rippled-server.md

@@ -48,4 +48,4 @@ There are several properties that define a good validator. The more of these pro
 * **Identified**. It should be clear who runs the validator. Ideally, a list of trusted validators should include validators operated by different owners in multiple legal jurisdictions and geographic areas, to reduce the chance that any localized events could interfere with the validator's impartial operation.
     * Setting up [Domain Verification](run-rippled-as-a-validator.html#domain-verification) is a good start.
 
-At present, Ripple (the company) cannot recommend any validators aside from those in the default validator list. However, we are collecting data on other validators and building tools to report on their performance. For metrics on validators, see [validators.ripple.com](https://validators.ripple.com).
+At present, Ripple (the company) cannot recommend any validators aside from those in the default validator list. However, we are collecting data on other validators and building tools to report on their performance. For metrics on validators, see the [XRPCharts Validator Registry](https://xrpcharts.ripple.com/#/validators).

content/news/known-amendments.md

@@ -383,5 +383,7 @@ Allows pre-authorization of accounting relationships (zero-balance trust lines)
 With this amendment enabled, a `TrustSet` transaction with [`tfSetfAuth` enabled](trustset.html#trustset-flags) can create a new [`RippleState` ledger object](ripplestate.html) even if it keeps all the other values of the `RippleState` node in their default state. The new `RippleState` node has the [`lsfLowAuth` or `lsfHighAuth` flag](ripplestate.html#ripplestate-flags) enabled, depending on whether the sender of the transaction is considered the low node or the high node. The sender of the transaction must have already enabled [`lsfRequireAuth`](accountroot.html#accountroot-flags) by sending an [AccountSet transaction](accountset.html) with the [asfRequireAuth flag enabled](accountset.html#accountset-flags).
 
 
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
 {% include '_snippets/rippled_versions.md' %}
-{% include '_snippets/tx-type-links.md' %}

content/references/rippled-api/api-conventions/basic-data-types.md

@@ -12,24 +12,28 @@ Each closed [Ledger](ledger-data-formats.html) has a [Ledger Index][] and a [Has
 [Address]: #addresses
 
 {% include '_snippets/data_types/address.md' %}
+<!--{#_ #}-->
 
 
 ## Hashes
 [Hash]: #hashes
 
 {% include '_snippets/data_types/hash.md' %}
+<!--{#_ #}-->
 
 
 ## Account Sequence
 [Sequence Number]: #account-sequence
 
 {% include '_snippets/data_types/account_sequence.md' %}
+<!--{#_ #}-->
 
 
 ## Ledger Index
 [Ledger Index]: #ledger-index
 
 {% include '_snippets/data_types/ledger_index.md' %}
+<!--{#_ #}-->
 
 
 ### Specifying Ledgers
@@ -119,6 +123,7 @@ Finally, if the recipient account of the payment trusts multiple issuers for a c
 [Currency Code]: #currency-codes
 
 {% include '_snippets/data_types/currency_code.md' %}
+<!--{#_ #}-->
 
 
 ## Specifying Time
@@ -126,3 +131,8 @@ Finally, if the recipient account of the payment trusts multiple issuers for a c
 The `rippled` server and its APIs represent time as an unsigned integer. This number measures the number of seconds since the "Ripple Epoch" of January 1, 2000 (00:00 UTC). This is like the way the [Unix epoch](http://en.wikipedia.org/wiki/Unix_time) works, except the Ripple Epoch is 946684800 seconds after the Unix Epoch.
 
 Don't convert Ripple Epoch times to UNIX Epoch times in 32-bit variables: this could lead to integer overflows.
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}

content/references/rippled-api/api-conventions/currency-formats.md

@@ -1,10 +1,11 @@
 # Currency Formats
 
-The XRP Ledger has [two kinds of money](money.html): XRP, and issued currencies. In the XRP Ledger, both types have high precision, although their formats are different.
+The XRP Ledger has two kinds of money: [XRP](xrp.html), and [issued currencies](issued-currencies.html). In the XRP Ledger, both types have high precision, although their formats are different.
 
 ## String Formatting
 
 {% include '_snippets/string-number-formatting.md' %}
+<!--{#_ #}-->
 
 ## XRP Precision
 
@@ -38,7 +39,7 @@ When transmitting non-XRP amounts across the network or recording them in ledger
 
 ## Currency Codes
 
-All non-XRP currencies in the XRP Ledger have a 160-bit currency code. The [`rippled` APIs](reference-rippled.html) map 3-character ASCII strings (case-sensitive) to 160-bit currency codes using a standard mapping. The currency code `XRP` is disallowed for issued currencies. Currencies with the same code can [ripple](rippling.html) across connected trustlines. Currency codes have no other behavior built into the XRP Ledger.
+All non-XRP currencies in the XRP Ledger have a 160-bit currency code. The [`rippled` APIs](rippled-api.html) map 3-character ASCII strings (case-sensitive) to 160-bit currency codes using a standard mapping. The currency code `XRP` is disallowed for issued currencies. Currencies with the same code can [ripple](rippling.html) across connected trustlines. Currency codes have no other behavior built into the XRP Ledger.
 
 ### Standard Currency Codes
 

content/references/rippled-api/api-conventions/error-formatting.md

@@ -99,7 +99,7 @@ For other errors that returned with HTTP status code 200 OK, the responses are f
 
 All methods can potentially return any of the following values for the `error` code:
 
-* `unknownCmd` - The request does not contain a [command](XREF: rippled-api.md) that the `rippled` server recognizes.
+* `unknownCmd` - The request does not contain a [command](rippled-api.html) that the `rippled` server recognizes.
 * `jsonInvalid` - (WebSocket only) The request is not a proper JSON object.
     * JSON-RPC returns a 400 Bad Request HTTP error in this case instead.
 * `missingCommand` - (WebSocket only) The request did not specify a `command` field.

content/references/rippled-api/api-conventions/modifying-the-ledger.md

@@ -4,7 +4,12 @@ All changes to the XRP Ledger happen as the result of transactions. The only API
 
 Transaction submission commands:
 
-- [`submit` command](XREF: submit.md)
+- [submit method][]
-- [`submit_multisigned` command](XREF: submit-multisigned.md)
+- [submit_multisigned method][]
 
-For more information on the various transactions you can submit, see the [Transaction Reference](xref: transaction-methods.html).
+For more information on the various transactions you can submit, see the [Transaction Formats Reference](transaction-formats.html).
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}

content/references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.md

@@ -1,7 +1,7 @@
 # SignerList
 [[Source]<br>](https://github.com/ripple/rippled/blob/6d2e3da30696bd10e3bb11a5ff6d45d2c4dae90f/src/ripple/protocol/impl/LedgerFormats.cpp#L127 "Source")
 
-The `SignerList` object type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. You can create, replace, or remove a SignerList using the [SignerListSet transaction type](reference-transaction-format.html#signerlistset). This object type is introduced by the [MultiSign amendment](known-amendments.html#multisign). [New in: rippled 0.31.0][]
+The `SignerList` object type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. You can create, replace, or remove a SignerList using a [SignerListSet transaction][]. This object type is introduced by the [MultiSign amendment](known-amendments.html#multisign). [New in: rippled 0.31.0][]
 
 ## Example {{currentpage.name}} JSON
 
@@ -64,11 +64,11 @@ Each member of the `SignerEntries` field is an object that describes that signer
 | `Account`         | String    | AccountID     | An XRP Ledger address whose signature contributes to the multi-signature. It does not need to be a funded address in the ledger. |
 | `SignerWeight`    | Number    | UInt16        | The weight of a signature from this signer. A multi-signature is only valid if the sum weight of the signatures provided meets or exceeds the SignerList's `SignerQuorum` value. |
 
-When processing a multi-signed transaction, the server dereferences the `Account` values with respect to the ledger at the time of transaction execution. If the address _does not_ correspond to a funded [AccountRoot object](#accountroot), then only the master secret associated with that address can be used to produce a valid signature. If the account _does_ exist in the ledger, then it depends on the state of that account. If the account has a Regular Key configured, the Regular Key can be used. The account's master key can only be used if it is not disabled. A multi-signature cannot be used as part of another multi-signature.
+When processing a multi-signed transaction, the server dereferences the `Account` values with respect to the ledger at the time of transaction execution. If the address _does not_ correspond to a funded [AccountRoot object](accountroot.html), then only the master secret associated with that address can be used to produce a valid signature. If the account _does_ exist in the ledger, then it depends on the state of that account. If the account has a Regular Key configured, the Regular Key can be used. The account's master key can only be used if it is not disabled. A multi-signature cannot be used as part of another multi-signature.
 
 ## SignerLists and Reserves
 
-A SignerList contributes to its owner's [reserve requirement](reserves.html). The SignerList itself counts as two objects, and each member of the list counts as one. As a result, the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line ([RippleState](#ripplestate)) or [Offer](#offer) object in the ledger.
+A SignerList contributes to its owner's [reserve requirement](reserves.html). The SignerList itself counts as two objects, and each member of the list counts as one. As a result, the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line ([RippleState](ripplestate.html)) or [Offer](offer.html) object in the ledger.
 
 ## SignerList ID Format
 

content/references/rippled-api/public-rippled-methods/account-methods/account_offers.md

@@ -52,7 +52,7 @@ A request can include the following parameters:
 | `account`      | String                                     | A unique identifier for the account, most commonly the account's [Address][]. |
 | `ledger`       | Unsigned integer, or String                | (Deprecated, Optional) A unique identifier for the ledger version to use, such as a ledger sequence number, a hash, or a shortcut such as "validated". |
 | `ledger_hash`  | String                                     | _(Optional)_ A 20-byte hex string identifying the ledger version to use. |
-| `ledger_index` | _(Optional)_ [Ledger Index][]              | (Optional, defaults to `current`) The sequence number of the ledger to use, or "current", "closed", or "validated" to select a ledger dynamically. (See [Specifying Ledgers](#specifying-ledgers)) |
+| `ledger_index` | _(Optional)_ [Ledger Index][]              | (Optional, defaults to `current`) The sequence number of the ledger to use, or "current", "closed", or "validated" to select a ledger dynamically. (See [Specifying Ledgers][]) |
 | `limit`        | Integer                                    | (Optional, default varies) Limit the number of transactions to retrieve. The server is not required to honor this value. Must be within the inclusive range 10 to 400. [New in: rippled 0.26.4][] |
 | `marker`       | [Marker][] | _(Optional)_ Value from a previous paginated response. Resume retrieving data where that response left off. [New in: rippled 0.26.4][] |
 
@@ -172,11 +172,11 @@ Each offer object contains the following fields:
 | `Field`      | Type             | Description                                |
 |:-------------|:-----------------|:-------------------------------------------|
 | `flags`      | Unsigned integer | Options set for this offer entry as bit-flags. |
-| `seq`        | Unsigned integer | Sequence number of the transaction that created this entry. (Transaction [sequence numbers](#account-sequence) are relative to accounts.) |
+| `seq`        | Unsigned integer | Sequence number of the transaction that created this entry. (Transaction [sequence numbers](basic-data-types.html#account-sequence) are relative to accounts.) |
 | `taker_gets` | String or Object | The amount the account accepting the offer receives, as a String representing an amount in XRP, or a currency specification object. (See [Specifying Currency Amounts][Currency Amount]) |
 | `taker_pays` | String or Object | The amount the account accepting the offer provides, as a String representing an amount in XRP, or a currency specification object. (See [Specifying Currency Amounts][Currency Amount]) |
 | `quality`    | String           | The exchange rate of the offer, as the ratio of the original `taker_pays` divided by the original `taker_gets`. When executing offers, the offer with the most favorable (lowest) quality is consumed first; offers with the same quality are executed from oldest to newest. [New in: rippled 0.29.0][] |
-| `expiration` | Unsigned integer | (May be omitted) A time after which this offer is considered unfunded, as [the number of seconds since the Ripple Epoch](#specifying-time). See also: [Offer Expiration](offers.html#offer-expiration). [New in: rippled 0.30.1][] |
+| `expiration` | Unsigned integer | (May be omitted) A time after which this offer is considered unfunded, as the number of [seconds since the Ripple Epoch][]. See also: [Offer Expiration](offers.html#offer-expiration). [New in: rippled 0.30.1][] |
 
 ## Possible Errors
 

content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/book_offers.md

@@ -161,7 +161,7 @@ The response follows the [standard format][], with a successful result containin
 | `ledger_index`         | Integer                                    | (Omitted if ledger\_current\_index provided instead) Sequence number, provided in the request, of the ledger version that was used when retrieving this data. |
 | `ledger_hash`          | String                                     | (May be omitted) Hex hash, provided in the request, of the ledger version that was used when retrieving this data. |
 | `marker`               | [Marker][] | (May be omitted) Server-defined value indicating the response is paginated. Pass this to the next call to resume where this call left off. Omitted when there are no pages of information after this one. |
-| `offers`               | Array                                      | Array of offer objects, each of which has the fields of an [OfferCreate transaction](reference-transaction-format.html#offercreate) |
+| `offers`               | Array                                      | Array of offer objects, each of which has the fields of an [OfferCreate transaction][] |
 
 In addition to the standard Offer fields, the following fields may be included in members of the `offers` array:
 
@@ -184,5 +184,7 @@ In addition to the standard Offer fields, the following fields may be included i
 * `badMarket` - The desired order book does not exist; for example, offers to exchange a currency for itself.
 
 
-{% include '_snippets/rippled_versions.md' %}
+<!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}

content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/path_find.md

@@ -1,7 +1,7 @@
 # path_find
 [[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/PathFind.cpp "Source")
 
-*WebSocket API only!* The `path_find` method searches for a [path](paths.html) along which a transaction can possibly be made, and periodically sends updates when the path changes over time. For a simpler version that is supported by JSON-RPC, see [`ripple_path_find`](#ripple-path-find). For payments occurring strictly in XRP, it is not necessary to find a path, because XRP can be sent directly to any account.
+*WebSocket API only!* The `path_find` method searches for a [path](paths.html) along which a transaction can possibly be made, and periodically sends updates when the path changes over time. For a simpler version that is supported by JSON-RPC, see the [ripple_path_find method][]. For payments occurring strictly in XRP, it is not necessary to find a path, because XRP can be sent directly to any account.
 
 There are three different modes, or sub-commands, of the path_find command. Specify which one you want with the `subcommand` parameter:
 
@@ -433,7 +433,7 @@ An example of a successful response:
 
 <!-- MULTICODE_BLOCK_END -->
 
-The initial response follows the [standard format](#response-formatting), with a successful result containing the following fields:
+The initial response follows the [standard format](response-formatting.html), with a successful result containing the following fields:
 
 | `Field`               | Type             | Description                       |
 |:----------------------|:-----------------|:----------------------------------|
@@ -455,7 +455,7 @@ Each element in the `alternatives` array is an object that represents a path fro
 
 * Any of the [universal error types][].
 * `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
-* `noEvents` - You are using a protocol that does not support asynchronous callbacks, for example JSON-RPC. (See [ripple\_path\_find](#ripple-path-find) for a pathfinding method that _is_ compatible with JSON-RPC.)
+* `noEvents` - You are using a protocol that does not support asynchronous callbacks, for example JSON-RPC. (See the [ripple_path_find method][] for a pathfinding method that _is_ compatible with JSON-RPC.)
 
 ### Asynchronous Follow-ups
 
@@ -530,7 +530,7 @@ If there was no outstanding pathfinding request, an error is returned instead.
 
 * Any of the [universal error types][].
 * `invalidParams` - If any fields are specified incorrectly, or any required fields are missing.
-* `noEvents` - If you tried to use this method on a protocol that does not support asynchronous callbacks, for example JSON-RPC. (See [ripple\_path\_find](#ripple-path-find) for a pathfinding method that _is_ compatible with JSON-RPC.)
+* `noEvents` - If you tried to use this method on a protocol that does not support asynchronous callbacks, for example JSON-RPC. (See the [ripple_path_find method][] for a pathfinding method that _is_ compatible with JSON-RPC.)
 * `noPathRequest` - You tried to close a pathfinding request when there is not an open one.
 
 ## path_find status
@@ -575,7 +575,7 @@ If there was no outstanding pathfinding request, an error is returned instead.
 
 * Any of the [universal error types][].
 * `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
-* `noEvents` - You are using a protocol that does not support asynchronous callbacks, for example JSON-RPC. (See [ripple\_path\_find](#ripple-path-find) for a pathfinding method that _is_ compatible with JSON-RPC.)
+* `noEvents` - You are using a protocol that does not support asynchronous callbacks, for example JSON-RPC. (See the [ripple_path_find method][] for a pathfinding method that _is_ compatible with JSON-RPC.)
 * `noPathRequest` - You tried to check the status of a pathfinding request when there is not an open one.
 
 

content/references/rippled-api/public-rippled-methods/transaction-methods/sign.md

@@ -3,7 +3,7 @@
 
 The `sign` method takes a [transaction in JSON format](transaction-formats.html) and a secret key, and returns a signed binary representation of the transaction. The result is always different, even when you provide the same transaction JSON and secret key. To contribute one signature to a multi-signed transaction, use the [sign_for method][] instead.
 
-**Caution:** Unless you run the `rippled` server yourself, you should do [local signing with RippleAPI](reference-rippleapi.html#sign) instead of using this command. An untrustworthy server could change the transaction before signing it, or use your secret key to sign additional arbitrary transactions as if they came from you.
+**Caution:** Unless you run the `rippled` server yourself, you should do [local signing with RippleAPI](rippleapi-reference.html#sign) instead of using this command. An untrustworthy server could change the transaction before signing it, or use your secret key to sign additional arbitrary transactions as if they came from you.
 
 ## Request Format
 An example of the request format:
@@ -85,7 +85,7 @@ The request includes the following parameters:
 | `key_type`     | String  | _(Optional)_ Type of cryptographic key provided in this request. Valid types are `secp256k1` or `ed25519`. Defaults to `secp256k1`. Cannot be used with `secret`. **Caution:** Ed25519 support is experimental. |
 | `offline`      | Boolean | (Optional, defaults to false) If true, when constructing the transaction, do not try to automatically fill in or validate values. |
 | `build_path`   | Boolean | _(Optional)_ If provided for a Payment-type transaction, automatically fill in the `Paths` field before signing. **Caution:** The server looks for the presence or absence of this field, not its value. This behavior may change. |
-| `fee_mult_max` | Integer | (Optional, defaults to 10; recommended value 1000) Limits how high the [automatically-provided `Fee` field](reference-transaction-format.html#auto-fillable-fields) can be. Signing fails with the error `rpcHIGH_FEE` if the current [load multiplier on the transaction cost](transaction-cost.html#local-load-cost) is greater than (`fee_mult_max` ÷ `fee_div_max`). Ignored if you specify the `Fee` field of the transaction ([transaction cost](transaction-cost.html)). |
+| `fee_mult_max` | Integer | (Optional, defaults to 10; recommended value 1000) Limits how high the [automatically-provided `Fee` field](transaction-common-fields.html#auto-fillable-fields) can be. Signing fails with the error `rpcHIGH_FEE` if the current [load multiplier on the transaction cost](transaction-cost.html#local-load-cost) is greater than (`fee_mult_max` ÷ `fee_div_max`). Ignored if you specify the `Fee` field of the transaction ([transaction cost](transaction-cost.html)). |
 | `fee_div_max`  | Integer | (Optional, defaults to 1) Signing fails with the error `rpcHIGH_FEE` if the current [load multiplier on the transaction cost](transaction-cost.html#local-load-cost) is greater than (`fee_mult_max` ÷ `fee_div_max`). Ignored if you specify the `Fee` field of the transaction ([transaction cost](transaction-cost.html)). [New in: rippled 0.30.1][] |
 
 ### Auto-Fillable Fields
@@ -98,7 +98,7 @@ The server automatically tries to fill in certain fields in `tx_json` (the [Tran
     * The `fee_mult_max` and `fee_div_max` parameters limit how high the automatically-provided transaction cost can be, in terms of the load-scaling multiplier that gets applied to the [reference transaction cost](transaction-cost.html#reference-transaction-cost). The default settings return an error if the automatically-provided value would use greater than a 10× multiplier. However, the production XRP Ledger [typically has a 1000× load multiplier](transaction-cost.html#current-transaction-cost).
     * The commandline syntax does not support `fee_mult_max` and `fee_div_max`. For the production XRP Ledger, you must provide a `Fee` value.
     * **Caution:** A malicious server can specify an excessively high transaction cost, ignoring the values of `fee_mult_max` and `fee_div_max`.
-* `Paths` - For Payment-type transactions (excluding XRP-to-XRP transfers), the Paths field can be automatically filled, as if you did a [ripple_path_find](#ripple-path-find). Only filled if `build_path` is provided.
+* `Paths` - For Payment-type transactions (excluding XRP-to-XRP transfers), the Paths field can be automatically filled, as if you used the [ripple_path_find method][]. Only filled if `build_path` is provided.
 
 ## Response Format
 

content/references/rippled-api/public-rippled-methods/transaction-methods/submit.md

@@ -260,7 +260,7 @@ The response follows the [standard format][], with a successful result containin
 | `tx_blob`               | String  | The complete transaction in hex string format |
 | `tx_json`               | Object  | The complete transaction in JSON format  |
 
-**Caution:** Even if the WebSocket response has `"status":"success"`, indicating that the command was successfully received, that does _not_ indicate that the transaction executed successfully. Many situations can prevent a transaction from processing successfully, such as a lack of trust lines connecting the two accounts in a payment, or changes in the state of the ledger since the time the transaction was constructed. Even if nothing is wrong, it may take several seconds to close and validate the ledger version that includes the transaction. See the [full list of transaction responses](reference-transaction-format.html#full-transaction-response-list) for details, and do not consider the transaction's results final until they appear in a validated ledger version.
+**Caution:** Even if the WebSocket response has `"status":"success"`, indicating that the command was successfully received, that does _not_ indicate that the transaction executed successfully. Many situations can prevent a transaction from processing successfully, such as a lack of trust lines connecting the two accounts in a payment, or changes in the state of the ledger since the time the transaction was constructed. Even if nothing is wrong, it may take several seconds to close and validate the ledger version that includes the transaction. See the [full list of transaction responses](transaction-results.html) for details, and do not consider the transaction's results final until they appear in a validated ledger version.
 
 **Caution:** If this command results in an error messages, the message can contain the secret key from the request. (This is not a problem if the request contained a signed tx_blob instead.) Make sure that these errors are not visible to others.
 

content/references/rippled-api/public-rippled-methods/transaction-methods/submit_multisigned.md

@@ -1,7 +1,7 @@
 # submit_multisigned
 [[Source]<br>](https://github.com/ripple/rippled/blob/release/src/ripple/rpc/handlers/SubmitMultiSigned.cpp "Source")
 
-The `submit_multisigned` command applies a [multi-signed](multi-signing.html) transaction and sends it to the network to be included in future ledgers. (You can also submit multi-signed transactions in binary form using the [`submit` command in submit-only mode](#submit-only-mode).)
+The `submit_multisigned` command applies a [multi-signed](multi-signing.html) transaction and sends it to the network to be included in future ledgers. (You can also submit multi-signed transactions in binary form using the [`submit` command in submit-only mode](submit.html#submit-only-mode).)
 
 This command requires the [MultiSign amendment](known-amendments.html#multisign) to be enabled. [New in: rippled 0.31.0][]
 

content/references/rippled-api/rippled-old-monolith.md

@@ -1,384 +0,0 @@
-# rippled API
-
-The core peer-to-peer server that manages the XRP Ledger is called `rippled`. Each `rippled` server connects to a network of peers, relays cryptographically signed transactions, and maintains a local copy of the complete shared global ledger. The source code for `rippled` is written in C++, and is [available on GitHub under an open-source license](https://github.com/ripple/rippled).
-
-* [`rippled` Setup](tutorial-rippled-setup.html)
-* [API Reference](#api-methods)
-* [Transaction Reference](transaction-formats.html)
-* JavaScript Client Library - [RippleAPI](reference-rippleapi.html)
-
-
-# WebSocket and JSON-RPC APIs
-
-If you want to communicate directly with a `rippled` server, you can use either the WebSocket API or the JSON-RPC API. Both APIs use the same list of commands, with almost entirely the same parameters in each command. Alternatively, you can use [RippleAPI](reference-rippleapi.html), which is a simplified JavaScript client library, which communicates directly with a `rippled` server from [Node.js](http://nodejs.org/) or a web browser.
-
-* The WebSocket API uses the [WebSocket protocol](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API), available in most browsers and Javascript implementations, to achieve persistent two-way communication. There is not a 1:1 correlation between requests and responses. Some requests prompt the server to send multiple messages back asynchronously; other times, responses may arrive in a different order than the requests that prompted them. The `rippled` server can be configured to accept secured (wss:), unsecured (ws:) WebSocket connections, or both.
-* The JSON-RPC API relies on request-response communication via HTTP or HTTPS. (The `rippled` server can be configured to accept HTTP, HTTPS, or both.) For commands that prompt multiple responses, you can provide a callback URL.
-
-In general, we recommend using WebSocket, because WebSocket's push paradigm has less latency and less network overhead. WebSocket is also more reliable; you can worry less about missing messages and establishing multiple connections. On the other hand, there is widespread support for JSON-RPC because you can use a standard HTTP library to connect to `rippled`'s JSON-RPC API.
-
-**Note:** The `rippled` program can also be used as a quick commandline client to make JSON-RPC requests to a running `rippled` server. The commandline interface is intended for administrative purposes only and is _not a supported API_.
-
-
-## Error Responses
-It is impossible to list all the possible ways an error can occur. Some may occur in the transport layer (for example, loss of network connectivity), in which case the results vary depending on what client and transport you are using. However, if the `rippled` server successfully receives your request, it tries to respond in a standardized error format.
-
-Some example errors:
-
-<!-- MULTICODE_BLOCK_START -->
-
-*WebSocket*
-
-```
-{
-  "id": 3,
-  "status": "error",
-  "type": "response",
-  "error": "ledgerIndexMalformed",
-  "request": {
-    "account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
-    "command": "account_info",
-    "id": 3,
-    "ledger_index": "-",
-    "strict": true
-  }
-}
-```
-
-*JSON-RPC*
-
-```
-HTTP Status: 200 OK
-{
-    "result": {
-        "error": "ledgerIndexMalformed",
-        "request": {
-            "account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
-            "command": "account_info",
-            "ledger_index": "-",
-            "strict": true
-        },
-        "status": "error"
-    }
-}
-```
-
-*Commandline*
-
-```
-{
-    "result": {
-        "error": "ledgerIndexMalformed",
-        "request": {
-            "account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
-            "command": "account_info",
-            "ledger_index": "-",
-            "strict": true
-        },
-        "status": "error"
-    }
-}
-```
-
-<!-- MULTICODE_BLOCK_END -->
-
-#### WebSocket API Error Response Format
-| `Field`   | Type     | Description                                           |
-|:----------|:---------|:------------------------------------------------------|
-| `id`      | (Varies) | ID provided in the Web Socket request that prompted this response |
-| `status`  | String   | `"error"` if the request caused an error              |
-| `type`    | String   | Typically `"response"`, which indicates a successful response to a command. |
-| `error`   | String   | A unique code for the type of error that occurred     |
-| `request` | Object   | A copy of the request that prompted this error, in JSON format. **Caution:** If the request contained any account secrets, they are copied here! |
-
-#### JSON-RPC API Error Response Format
-Some JSON-RPC request respond with an error code on the HTTP layer. In these cases, the response is a plain-text explanation in the response body. For example, if you forgot to specify the command in the `method` parameter, the response is like this:
-
-```
-HTTP Status: 400 Bad Request
-Null method
-```
-
-For other errors that returned with HTTP status code 200 OK, the responses are formatted in JSON, with the following fields:
-
-| `Field`          | Type   | Description                                      |
-|:-----------------|:-------|:-------------------------------------------------|
-| `result`         | Object | Object containing the response to the query      |
-| `result.error`   | String | A unique code for the type of error that occurred |
-| `result.status`  | String | `"error"` if the request caused an error         |
-| `result.request` | Object | A copy of the request that prompted this error, in JSON format. **Caution:** If the request contained any account secrets, they are copied here! **Note:** The request is re-formatted in WebSocket format, regardless of the request made. |
-
-### Caution on Errors
-
-When your request results in an error, the entire request is copied back as part of the response, so that you can try to debug the error. However, this also includes any secrets that were passed as part of the request. When sharing error messages, be very careful not to accidentally expose important account secrets to others.
-
-### Universal Errors
-
-All methods can potentially return any of the following values for the `error` code:
-
-* `unknownCmd` - The request does not contain a [command](#api-methods) that the `rippled` server recognizes.
-* `jsonInvalid` - (WebSocket only) The request is not a proper JSON object.
-    * JSON-RPC returns a 400 Bad Request HTTP error in this case instead.
-* `missingCommand` - (WebSocket only) The request did not specify a `command` field.
-    * JSON-RPC returns a 400 Bad Request HTTP error in this case instead.
-* `tooBusy` - The server is under too much load to do this command right now. Generally not returned if you are connected as an admin.
-* `noNetwork` - The server is having trouble connecting to the rest of the XRP Ledger peer-to-peer network (and is not running in stand-alone mode).
-* `noCurrent` - The server does not know what the current ledger is, due to high load, network problems, validator failures, incorrect configuration, or some other problem.
-* `noClosed` - The server does not have a closed ledger, typically because it has not finished starting up.
-* `wsTextRequired` - (WebSocket only) The request's [opcode](https://tools.ietf.org/html/rfc6455#section-5.2) is not text.
-
-
-## Changes to the APIs
-
-The WebSocket and JSON-RPC APIs are still in development, and are subject to change. If you want to be notified of upcoming changes and future versions of `rippled`, subscribe to the Ripple Server mailing list:
-
-[https://groups.google.com/forum/#!forum/ripple-server](https://groups.google.com/forum/#!forum/ripple-server)
-
-## Formatting Conventions
-
-The WebSocket and JSON-RPC APIs generally take the same arguments, although they're provided in a different way (See [Request Formatting](#request-formatting) for details). Many similar parameters appear throughout the APIs, and there are conventions for how to specify these parameters.
-
-All field names are case-sensitive. In responses, fields that are taken directly from ledger objects or transaction instructions start with upper-case letters. Other fields, including ones that are dynamically generated for a response, are lower case.
-
-## Basic Data Types
-
-Different types of objects are uniquely identified in different ways:
-
-[Accounts](accounts.html) are identified by their [Address][], for example `"r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"`. Addresses always start with "r". Many `rippled` methods also accept a hexadecimal representation.
-
-[Transactions](transaction-formats.html) are identified by a [Hash][] of the transaction's binary format. You can also identify a transaction by its sending account and [Sequence Number][].
-
-Each closed [Ledger](reference-ledger-format.html) has a [Ledger Index][] and a [Hash][] value. When [Specifying a Ledger Instance](#specifying-ledgers) you can use either one.
-
-### Addresses
-[Address]: #addresses
-
-{% include '_snippets/data_types/address.md' %}
-
-
-### Hashes
-[Hash]: #hashes
-
-{% include '_snippets/data_types/hash.md' %}
-
-
-### Account Sequence
-[Sequence Number]: #account-sequence
-
-{% include '_snippets/data_types/account_sequence.md' %}
-
-
-### Ledger Index
-[Ledger Index]: #ledger-index
-
-{% include '_snippets/data_types/ledger_index.md' %}
-
-
-### Specifying Ledgers
-
-Many API methods require you to specify an instance of the ledger, with the data retrieved being considered up-to-date as of that particular version of the shared ledger. The commands that accept a ledger version all work the same way. There are three ways you can specify which ledger you want to use:
-
-1. Specify a ledger by its [Ledger Index][] in the `ledger_index` parameter. Each closed ledger has an identifying sequence number that is 1 higher than the previously-validated ledger. (The Genesis Ledger has sequence number 0)
-2. Specify a ledger by its [Hash][] value in the `ledger_hash` parameter.
-3. Specify a ledger by one of the following shortcuts, in the `ledger_index` parameter:
-    * `validated` for the most recent ledger that has been validated by the whole network
-    * `closed` for the most recent ledger that has been closed for modifications and proposed for validation
-    * `current` for the server's current working version of the ledger.
-
-There is also a deprecated `ledger` parameter which accepts any of the above three formats. *Do not* use this parameter; it may be removed without further notice.
-
-If you do not specify a ledger, the `current` (in-progress) ledger is chosen by default. If you provide more than one field specifying ledgers, the deprecated `ledger` field is used first if it exists, falling back to `ledger_hash`. The `ledger_index` field is ignored unless neither of the other two are present.
-
-**Note:** Do not rely on this default behavior for specifying a ledger; it is subject to change. Always specify a ledger version in the request if you can.
-
-
-## Currencies
-
-There are two kinds of currencies in the XRP Ledger: XRP, and everything else. There are many differences between the two:
-
-| `XRP`                                                           | Issued Currencies |
-|:----------------------------------------------------------------|:-----------|
-| Has no issuer.                                                  | Always issued by an XRP Ledger account |
-| Specified as a string                                           | Specified as an object |
-| Tracked in [accounts](accountroot.html) | Tracked in [trust lines](reference-ledger-format.html#ripplestate) |
-| Can never be created; can only be destroyed                     | Can be issued or redeemed freely |
-| Maximum value `100000000000` (`1e11`)                           | Maximum value `9999999999999999e80` |
-| Precise to the nearest ["drop"](#xrp) (0.000001 XRP)            | 15 decimal digits of precision, with a minimum nonzero absolute value of `1000000000000000e-96` |
-
-**Caution:** The XRP Ledger uses decimal math with different precision than typical floating-point numbers, so currency amounts are always presented as strings.
-
-### Specifying Currency Amounts
-
-Some API methods require you to specify an amount of currency. Depending on whether you are dealing in the network's native XRP currency or other currency units (called _issuances_), the style for specifying it is very different.
-
-#### XRP
-[drops of XRP]: #xrp
-[XRP, in drops]: #xrp
-
-Amounts of XRP are represented as strings. (XRP has precision equivalent to a 64-bit integer, but JSON integers are limited to 32 bits, so XRP can overflow if represented in a JSON integer.) XRP is formally specified in "drops", which are equivalent to 0.000001 (one 1-millionth) of an XRP each. Thus, to represent 1.0 XRP in a JSON document, you would write:
-
-```
-"1000000"
-```
-
-**Do not specify XRP as an object.**
-
-Unit tests are permitted to submit values of XRP (not drops) with a decimal point - for example, "1.23" meaning 1.23 XRP. All other cases should always specify XRP in drops, with no decimal point: e.g. "1230000" meaning 1.23 XRP.
-
-#### Non-XRP
-
-If you are specifying non-XRP currency (including fiat dollars, precious metals, cryptocurrencies, or other custom currency) you must specify it with a currency specification object. This is a JSON object with three fields:
-
-| `Field`    | Type                       | Description                        |
-|:-----------|:---------------------------|:-----------------------------------|
-| `currency` | String - [Currency Code][] | Arbitrary code for currency to issue. Cannot be `XRP`. |
-| `value`    | String                     | Quoted decimal representation of the amount of currency. This can include scientific notation, such as `1.23e11` meaning 123,000,000,000. Both `e` and `E` may be used. |
-| `issuer`   | String                     | Unique account address of the entity issuing the currency. In other words, the person or business where the currency can be redeemed. |
-
-**Caution:** These field names are case-sensitive.
-
-For example, to represent $153.75 US dollars issued by account `r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59`, you would specify:
-
-```
-{
-    "currency": "USD",
-    "value": "153.75",
-    "issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"
-}
-```
-
-Unit tests are permitted to submit amounts of non-XRP currencies as a slash-separated string in the format `"amount/currency/issuer"`. All other cases should use the JSON object format above.
-
-#### Specifying Currencies Without Amounts
-
-If you are specifying a non-XRP currency without an amount (typically for defining an order book of currency exchange offers) you should specify it as above, but omit the `value` field.
-
-If you are specifying XRP without an amount (typically for defining an order book) you should specify it as a JSON object with _only_ a `currency` field. Never include an `issuer` field for XRP.
-
-Finally, if the recipient account of the payment trusts multiple issuers for a currency, you can indicate that the payment should be made in any combination of issuers that the recipient accepts. To do this, specify the recipient account's address as the `issuer` value in the JSON object.
-
-### Currency Codes
-[Currency Code]: #currency-codes
-
-{% include '_snippets/data_types/currency_code.md' %}
-
-
-## Specifying Time
-
-The `rippled` server and its APIs represent time as an unsigned integer. This number measures the number of seconds since the "Ripple Epoch" of January 1, 2000 (00:00 UTC). This is like the way the [Unix epoch](http://en.wikipedia.org/wiki/Unix_time) works, except the Ripple Epoch is 946684800 seconds after the Unix Epoch.
-
-Don't convert Ripple Epoch times to UNIX Epoch times in 32-bit variables: this could lead to integer overflows.
-
-## Possible Server States
-
-Depending on how the `rippled` server is configured, how long it has been running, and other factors, a server may be participating in the global XRP Ledger peer-to-peer network to different degrees. This is represented as the `server_state` field in the responses to the [`server_info`](#server-info) and [`server_state`](#server-state) commands. The possible responses follow a range of ascending interaction, with each later value superseding the previous one. Their definitions are as follows (in order of increasing priority):
-
-| `Value`        | Description                                                 |
-|:---------------|:------------------------------------------------------------|
-| `disconnected` | The server is not connected to the XRP Ledger peer-to-peer network whatsoever. It may be running in offline mode, or it may not be able to access the network for whatever reason. |
-| `connected`    | The server believes it is connected to the network.         |
-| `syncing`      | The server is currently behind on ledger versions. (It is normal for a server to spend a few minutes catching up after you start it.) |
-| `tracking`     | The server is in agreement with the network                 |
-| `full`         | The server is fully caught-up with the network and could participate in validation, but is not doing so (possibly because it has not been configured as a validator). |
-| `validating`   | The server is currently participating in validation of the ledger |
-| `proposing`    | The server is participating in validation of the ledger and currently proposing its own version. |
-
-**Note:** The distinction between `full`, `validating`, and `proposing` is based on synchronization with the rest of the global network, and it is normal for a server to fluctuate between these states as a course of general operation.
-
-## Markers and Pagination
-
-Some methods return more data than can efficiently fit into one response. When there are more results than contained, the response includes a `marker` field. You can use this to retrieve more pages of data across multiple calls. In each request, pass the `marker` value from the previous response to resume from the point where you left off. If the `marker` is omitted from a response, then you have reached the end of the data set.
-
-The format of the `marker` field is intentionally undefined. Each server can define a `marker` field as desired, so it may take the form of a string, a nested object, or another type. Different servers, and different methods provided by the same server, can have different `marker` definitions. Each `marker` is ephemeral, and may not work as expected after 10 minutes.
-
-
-## Modifying the Ledger
-
-All changes to the XRP Ledger happen as the result of transactions. The only API methods that can change the contents of the XRP Ledger are the commands that submit transactions. Even then, changes only apply permanently if the transactions are approved by the [consensus process](consensus.html). Most other public methods represent different ways to view the data represented in the XRP Ledger, or request information about the state of the server.
-
-Transaction submission commands:
-
-- [`submit` command](#submit)
-- [`submit_multisigned` command](#submit-multisigned)
-
-For more information on the various transactions you can submit, see the [Transaction Reference](transaction-formats.html).
-
-
-
-# API Methods
-
-API methods for the Websocket and JSON-RPC APIs are defined by command names, and are divided into Public Commands and Admin Commands. Public Commands are not necessarily meant for the general public, but they are used by any client attached to the server. (Think of Public Commands as being for members or customers of the organization running the server, while the Admin Commands are for the personnel in charge of keeping the server operational.) Public Commands include operations such as checking the state of the ledger, finding a path to connecting users, and submitting a transaction, among others. Admin Commands, on the other hand, are meant only for trusted server operators, and include commands for managing, monitoring, and debugging the server.
-
-
-
-## Commandline Access
-
-You can use the `rippled` application (as a separate instance) as a JSON-RPC client. In this mode, it has syntax for triggering most API methods with a single line from the command prompt, as described in each method. However, some methods or options don't have commandline syntax. For otherwise unsupported syntax, you can use the following method:
-
-**Note:** The commandline interface is intended for administrative purposes only and is _not a supported API_.
-
-
-# Account Information
-
-For more information, see [Accounts](accounts.html).
-
-{% include 'rippled-api-methods/wallet_propose.md' %}
-
-# Ledger Information
-
-{% include 'rippled-api-methods/ledger_request.md' %}
-
-{% include 'rippled-api-methods/ledger_accept.md' %}
-
-# Transactions
-<!-- TODO: Took the main overview and put it in the blurb for the Transactions landing page. Needed to leave the content below b/c it contains links that the blurb can't handle. Need to find a home for this. -->
-There are several sources of complication in transactions. Unlike traditional banking, where a trusted third party (the bank, or the [ACH](http://en.wikipedia.org/wiki/Automated_Clearing_House)) verifies the participants' identities and ensures their balances are adjusted accurately, Ripple uses cryptography and decentralized computing power to do the same thing. Sending XRP requires no third party aside from the distributed network itself. However, the XRP Ledger also supports issuing balances in any currency and trading them in a decentralized exchange. This brings far more power, but it also means that the system must account for [counterparty risk](http://en.wikipedia.org/wiki/Counterparty_risk#Counterparty_risk), currency conversions, and other issues. The XRP Ledger must be robust to keep track of which transactions have been completely validated, even when subject to hardware failures, attacks, or natural disasters.
-
-# Subscriptions
-
-
-# Server Information
-
-There are also commands that retrieve information about the current state of the server. These may be useful for monitoring the health of the server, or in preparing for making other API methods. For example, you may query for the current fee schedule before sending a transaction, or you may check which ledger versions are available before digging into the ledger history for a specific record.
-
-{% include 'rippled-api-methods/can_delete.md' %}
-
-{% include 'rippled-api-methods/consensus_info.md' %}
-
-{% include 'rippled-api-methods/fetch_info.md' %}
-
-{% include 'rippled-api-methods/feature.md' %}
-
-{% include 'rippled-api-methods/get_counts.md' %}
-
-{% include 'rippled-api-methods/ledger_cleaner.md' %}
-
-{% include 'rippled-api-methods/log_level.md' %}
-
-{% include 'rippled-api-methods/logrotate.md' %}
-
-{% include 'rippled-api-methods/validation_create.md' %}
-
-{% include 'rippled-api-methods/validation_seed.md' %}
-
-{% include 'rippled-api-methods/validators.md' %}
-
-{% include 'rippled-api-methods/validator_list_sites.md' %}
-
-{% include 'rippled-api-methods/peers.md' %}
-
-{% include 'rippled-api-methods/print.md' %}
-
-
-# Convenience Functions
-
-The `rippled` server also provides a few commands purely for convenience.
-
-{% include 'rippled-api-methods/connect.md' %}
-
-{% include 'rippled-api-methods/stop.md' %}
-
-
-
-{% include '_snippets/rippled_versions.md' %}
-{% include '_snippets/tx-type-links.md' %}

content/references/rippled-api/transaction-formats/transaction-format-old-monolith.md

@@ -1,58 +0,0 @@
-# Transactions Overview
-
-
-### Reliable Transaction Submission
-
-Reliably submitting transactions is the process of achieving both of the following:
-
-* Idempotency - A transaction should be processed once and only once, or not at all.
-* Verifiability - Applications can determine the final result of a transaction.
-
-To have both qualities when submitting a transaction, an application should:
-
-1. Construct and sign the transaction first, including a [`LastLedgerSequence`](reliable-transaction-submission.html#lastledgersequence) parameter that gives the transaction a limited lifespan.
-2. Persist details of the transaction before submitting.
-3. Submit the transaction.
-4. Confirm that the transaction was either included in a validated ledger, or that it has expired due to `LastLedgerSequence`.
-5. If a transaction fails or expires, you can modify and resubmit it.
-
-Main article: [Reliable Transaction Submission](reliable-transaction-submission.html)
-
-
-
-### Canceling or Skipping a Transaction
-
-An important and intentional feature of the XRP Ledger is that a transaction is final as soon as it has been incorporated in a validated ledger.
-
-However, if a transaction has not yet been included in a validated ledger, you can effectively cancel it by rendering it invalid. Typically, this means sending another transaction with the same `Sequence` value from the same account. If you do not want the replacement transaction to do anything, send an [AccountSet](#accountset) transaction with no options.
-
-For example, if you try to submit 3 transactions with sequence numbers 11, 12, and 13, but transaction 11 gets lost somehow or does not have a high enough [transaction cost](#transaction-cost) to be propagated to the network, then you can cancel transaction 11 by submitting an AccountSet transaction with no options and sequence number 11. This does nothing (except destroying the transaction cost for the new transaction 11), but it allows transactions 12 and 13 to become valid.
-
-This approach is preferable to renumbering and resubmitting transactions 12 and 13, because it prevents transactions from being effectively duplicated under different sequence numbers.
-
-In this way, an AccountSet transaction with no options is the canonical "[no-op](http://en.wikipedia.org/wiki/NOP)" transaction.
-
-
-
-
-
-
-# Transaction Results
-
-## Looking up Transaction Results
-
-To see the final result of a transaction, use the [tx method][], [account_tx method][], or other response from `rippled`. Look for `"validated": true` to indicate that this response uses a ledger version that has been validated by consensus.
-
-| Field                  | Value   | Description                               |
-|:-----------------------|:--------|:------------------------------------------|
-| meta.TransactionResult | String  | A code that categorizes the result, such as `tecPATH_DRY` |
-| validated              | Boolean | Whether or not this result comes from a validated ledger. If `false`, then the result is provisional. If `true`, then the result is final. |
-
-```js
-    "hash": "E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7",
-    "meta": {
-      ...
-      "TransactionResult": "tesSUCCESS"
-    },
-    "validated": true
-```

content/references/rippled-api/transaction-formats/transaction-results/tec-codes.md

@@ -2,7 +2,7 @@
 
 These codes indicate that the transaction failed, but it was applied to a ledger to apply the [transaction cost](transaction-cost.html). They have numerical values in the range 100 to 199. Ripple recommends using the text code, not the numeric value.
 
-For the most part, transactions with `tec` codes take no action other than to destroy the XRP paid as a [transaction cost](transaction-cost.html), but there are some exceptions. As an exception, a transaction that results in `tecOVERSIZE` still cleans up some [unfunded offers](#lifecycle-of-an-offer). Always look at the [transaction metadata](transaction-metadata.html) to see precisely what a transaction did.
+For the most part, transactions with `tec` codes take no action other than to destroy the XRP paid as a [transaction cost](transaction-cost.html), but there are some exceptions. As an exception, a transaction that results in `tecOVERSIZE` still cleans up some [unfunded offers](offers.html#lifecycle-of-an-offer). Always look at the [transaction metadata](transaction-metadata.html) to see precisely what a transaction did.
 
 **Caution:** A transaction that provisionally failed with a `tec` code may still succeed or fail with a different code after being reapplied. The result is final when it appears in a validated ledger version. For more information, see [Finality of Results](finality-of-results.html) and [Reliable Transaction Submission](reliable-transaction-submission.html).
 

content/tutorials/get-started/get-started-with-the-rippled-api.md

@@ -201,7 +201,7 @@ The fields of a successful response include:
 | `id`            | (Varies) | (WebSocket only) ID provided in the request that prompted this response |
 | `status`        | String   | (WebSocket only) The value `success` indicates the request was successfully received and understood by the server. |
 | `result.status` | String   | (JSON-RPC and Commandline) The value `success` indicates the request was successfully received and understood by the server. |
-| `type`          | String   | (WebSocket only) The value `response` indicates a successful response to a command. [Asynchronous notifications](subscriptions.html) use a different value such as `ledgerClosed` or `transaction`. |
+| `type`          | String   | (WebSocket only) The value `response` indicates a successful response to a command. [Asynchronous notifications](subscribe.html) use a different value such as `ledgerClosed` or `transaction`. |
 | `result`        | Object   | The result of the query; contents vary depending on the command. |
 
 ### Commandline

content/tutorials/manage-the-rippled-server/install-rippled.md

@@ -88,3 +88,17 @@ You can use the [rippled commandline interface](get-started-with-the-rippled-api
     $ /opt/ripple/bin/rippled <METHOD>
 
 For a full list of available methods, see the [rippled API reference](rippled-api.html).
+
+### Additional Configuration
+
+`rippled` should connect to the XRP Ledger with the default configuration. However, you can change your settings by editing the `rippled.cfg` file (located at `/opt/ripple/etc/rippled.cfg` when installing `rippled` with yum). For recommendations about configuration settings, see [Capacity Planning](capacity-planning.html).
+
+See [the `rippled` GitHub repository](https://github.com/ripple/rippled/blob/master/doc/rippled-example.cfg) for a description of all configuration options.
+
+Changes to the `[debug_logfile]` or `[database_path]` sections may require you to give the `rippled` user and group ownership to your new configured path:
+
+        $ chown -R rippled:rippled <configured path>
+
+Restart `rippled` for any configuration changes to take effect:
+
+        $ sudo service rippled restart

content/tutorials/manage-the-rippled-server/rippled-setup.md

@@ -1,24 +0,0 @@
-# Operating rippled Servers
-
-The core server of the XRP Ledger peer-to-peer network is [`rippled`](the-rippled-server.html). Anyone can run their own `rippled` server that follows the network and keeps a complete copy of the XRP Ledger. You can even have your server take part in the consensus process.
-
-This page contains instructions for:
-
-* [Capacity Planning for `rippled`](#capacity-planning)
-* [Installing `rippled`](#installing-rippled)
-* [Participating in the Consensus Process](#running-a-validator)
-
-
-# Additional Configuration
-
-`rippled` should connect to the XRP Ledger with the default configuration. However, you can change your settings by editing the `rippled.cfg` file (located at `/opt/ripple/etc/rippled.cfg` when installing `rippled` with yum). For recommendations about configuration settings, see [Capacity Planning](#capacity-planning).
-
-See [the `rippled` GitHub repository](https://github.com/ripple/rippled/blob/release/doc/rippled-example.cfg) for a description of all configuration options.
-
-Changes to the `[debug_logfile]` or `[database_path]` sections may require you to give the `rippled` user and group ownership to your new configured path:
-
-        $ chown -R rippled:rippled <configured path>
-
-Restart `rippled` for any configuration changes to take effect:
-
-        $ sudo service rippled restart

content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md

@@ -1,4 +1,4 @@
-# Becoming an XRP Ledger Gateway
+# Become an XRP Ledger Gateway
 
 **Gateways** are the businesses that link the XRP Ledger to the rest of the world. An existing online financial institution can expand to act as a gateway in the the XRP Ledger. By becoming an XRP Ledger gateway, a financial services business can gain several advantages:
 

content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md

@@ -1,4 +1,4 @@
-# Listing XRP as an Exchange
+# List XRP as an Exchange
 
 This document describes the steps that an exchange needs to take to list XRP. For details about other aspects of `rippled` and the XRP Ledger, see the  [Ripple Developer Center](https://ripple.com/build).
 

dactyl-config.yml

@@ -622,8 +622,8 @@ pages:
         targets:
             - local
 
-    -   md: tutorials/use-simple-xrp-payments/send-a-multisigned-transaction.md
+    -   md: tutorials/use-simple-xrp-payments/send-a-multi-signed-transaction.md
-        html: send-a-multisigned-transaction.html
+        html: send-a-multi-signed-transaction.html
         funnel: Docs
         doc_type: Tutorials
         category: Manage Account Settings
@@ -2384,12 +2384,6 @@ ignore_anchors_in:
 #Sometimes, a link is not really problematic, but the link checker detects it
 # as such and the easiest solution is to ignore it.
 known_broken_links:
-    # Strangely, Python doesn't like the cert here. Firefox is OK with it.
-    - https://validators.ripple.com
-
-    # Login required for the client portal.
-    - https://clients.ripple.com/
-
     # These PDFs download OK in a browser
     - http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32015R0847
     - http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:345:0001:0009:EN:PDF

old-dactyl-config.yml

@@ -1,556 +0,0 @@
-# Relative paths work OK as long as you start the tool from its local dir
-template_path: tool
-
-# This folder gets copied into the output directory
-template_static_path: assets
-
-# Templates should have filenames starting in template-
-default_template: template-doc.html
-default_pdf_template: template-forpdf.html
-
-# HTML, PDF, GFM all get output here
-out_path: out
-
-# MD files should be here (and in subdirs)
-content_path: content
-
-# This folder gets copied into the output directory
-content_static_path: img
-
-# PDF creation needs a dir for temporary files
-temporary_files_path: /tmp/
-
-default_filters:
-    - multicode_tabs
-    - standardize_header_ids
-    - buttonize
-    - callouts
-    - badges
-    - link_replacement
-
-callout_class: "devportal-callout"
-
-cover_page:
-    name: Overview
-    html: index.html
-    template: template-index.html
-
-targets:
-    # First member is the default that gets built when target not specified
-    -   name: local
-        display_name: Ripple Developer Portal
-        # These github_ fields are used by the template's "Edit on GitHub" link.
-        #  Override them with --vars to change which fork/branch to edit.
-        github_forkurl: https://github.com/ripple/ripple-dev-portal
-        github_branch: master
-
-    -   name: ripple.com
-        display_name: Ripple Developer Center
-        github_forkurl: https://github.com/ripple/ripple-dev-portal
-        github_branch: master
-        template: template-contentwithtoc.html
-        link_subs:
-            "reference-rippled.html": https://ripple.com/build/rippled-apis/
-            "reference-rippleapi.html": https://ripple.com/build/rippleapi/
-            "reference-transaction-format.html": https://ripple.com/build/transactions/
-            "reference-ledger-format.html": https://ripple.com/build/ledger-format/
-            "reference-data-api.html": https://ripple.com/build/data-api-v2/
-            "reference-amendments.html": https://ripple.com/build/known-amendments/
-            "tutorial-multisign.html": https://ripple.com/build/how-to-multi-sign/
-            "concept-issuing-and-operational-addresses.html": https://ripple.com/build/issuing-operational-addresses/
-            "tutorial-reliable-transaction-submission.html": https://ripple.com/build/reliable-transaction-submission/
-            "tutorial-rippleapi-beginners-guide.html": https://ripple.com/build/rippleapi-beginners-guide/
-            "tutorial-rippled-setup.html": https://ripple.com/build/rippled-setup/
-            "tutorial-gateway-guide.html": https://ripple.com/build/gateway-guide/
-            "tutorial-paychan.html": https://ripple.com/build/payment-channels-tutorial/
-            "tutorial-escrow.html": https://ripple.com/build/escrow-tutorials/
-            "tutorial-listing-xrp.html": https://ripple.com/build/listing-xrp-exchange/
-            "concept-cryptographic-keys.html": https://ripple.com/build/cryptographic-keys/
-            "tutorial-regular-keys.html": https://ripple.com/build/working-regular-key-pair/
-            "tutorial-build-run-rippled-ubuntu.html": https://ripple.com/build/build-run-rippled-ubuntu/
-            "concept-accounts.html": https://ripple.com/build/accounts/
-            "concept-amendments.html": https://ripple.com/build/amendments/
-            "concept-authorized-trust-lines.html": https://ripple.com/build/authorized-trust-lines/
-            "concept-checks.html": https://ripple.com/build/checks/
-            "concept-consensus.html": https://ripple.com/build/xrp-ledger-consensus-process/
-            "concept-escrow.html": https://ripple.com/build/escrow/
-            "concept-reaching-consensus.html": https://ripple.com/build/reaching-consensus-xrp-ledger/
-            "concept-history-sharding.html": https://ripple.com/build/history-sharding/
-            "concept-fee-voting.html": https://ripple.com/build/fee-voting/
-            "concept-fees.html": https://ripple.com/build/fees-disambiguation/
-            "concept-freeze.html": https://ripple.com/build/freeze/
-            "concept-paths.html": https://ripple.com/build/paths/
-            "concept-partial-payments.html": https://ripple.com/build/partial-payments/
-            "concept-reserves.html": https://ripple.com/build/reserves/
-            "concept-stand-alone-mode.html": https://ripple.com/build/stand-alone-mode/
-            "concept-transaction-cost.html": https://ripple.com/build/transaction-cost/
-            "concept-transfer-fees.html": https://ripple.com/build/transfer-fees/
-            "concept-noripple.html": https://ripple.com/build/understanding-the-noripple-flag/
-            "concept-xrp-ledger-intro.html": https://ripple.com/build/xrp-ledger-introduction/
-            "gb-2015-06.html": https://ripple.com/build/gateway-guide/gb-2015-06-corrections-autobridging/
-            "gb-2015-05.html": https://ripple.com/build/gateway-guide/gb-2015-05-historical-ledger-query-migration/
-            "ripple-api-tool.html": https://ripple.com/build/websocket-tool/
-            "data-api-v2-tool.html": https://ripple.com/build/data-api-tool/
-            "concept-money.html": https://ripple.com/build/money-xrp-ledger/
-            "reference-currency.html": https://ripple.com/build/currency-format/
-            "concept-demurrage.html": https://ripple.com/build/demurrage/
-            "concept-depositauth.html": https://ripple.com/build/deposit-authorization/
-            "tutorial-checks-send.html": https://ripple.com/build/how-to-send-a-check/
-            "tutorial-checks-lookup-by-sender.html": https://ripple.com/build/look-checks-sender/
-            "tutorial-checks-lookup-by-recipient.html": https://ripple.com/build/look-checks-recipient/
-            "tutorial-checks-cancel.html": https://ripple.com/build/how-to-cancel-a-check/
-            "tutorial-checks-cash-exact.html": https://ripple.com/build/cash-check-exact-amount/
-            "tutorial-checks-cash-flex.html": https://ripple.com/build/cash-check-flexible-amount/
-        image_subs:
-            "img/funds_flow_diagram.png": https://cdn.ripple.com/wp-content/uploads/2016/03/funds_flow_diagram.png
-            "img/checks-happy_path.png": https://cdn.ripple.com/wp-content/uploads/2018/03/checks-happy_path.png
-            "img/checks_expiration.png": https://cdn.ripple.com/wp-content/uploads/2018/03/checks_expiration.png
-            "img/e2g-01.png": https://ripple.com/wp-content/themes/ripple-beta/assets/img/e2g-01.png
-            "img/e2g-02.png": https://ripple.com/wp-content/themes/ripple-beta/assets/img/e2g-02.png
-            "img/e2g-03.png": https://ripple.com/wp-content/themes/ripple-beta/assets/img/e2g-03.png
-            "img/e2g-with_transferrate.png": https://ripple.com/wp-content/themes/ripple-beta/assets/img/e2g-with_transferrate.png
-            "img/transfer_fees_example.png": https://cdn.ripple.com/wp-content/uploads/2015/06/transfer_fees_example1.png
-            "img/ledger-process.png": https://ripple.com/wp-content/themes/ripple-beta/assets/img/ledger-process.png
-            "img/ledger-components.png": https://ripple.com/wp-content/themes/ripple-beta/assets/img/ledger-components.png
-            "img/ledger-indexes.png": https://ripple.com/wp-content/themes/ripple-beta/assets/img/ledger-indexes.png
-            "img/ledger-history.png": https://cdn.ripple.com/wp-content/uploads/2014/12/Overview-of-Ripple-Ledger-Consensus-and-Validation-12_12-02.png
-            "img/ledger-changes.png": https://cdn.ripple.com/wp-content/uploads/2014/12/Overview-of-Ripple-Ledger-Consensus-and-Validation-12_12-03.png
-            "img/paths-examples.png": https://ripple.com/wp-content/themes/ripple-beta/assets/img/paths-examples.png
-            "img/paths-default_paths.png": https://ripple.com/wp-content/themes/ripple-beta/assets/img/paths-default_paths.png
-            "img/noripple-01.png": https://cdn.ripple.com/wp-content/uploads/2015/04/noripple-01.png
-            "img/noripple-02.png": https://cdn.ripple.com/wp-content/uploads/2015/04/noripple-02.png
-            "img/noripple-03.png": https://cdn.ripple.com/wp-content/uploads/2015/01/noripple-03.png
-            "img/noripple-04.png": https://cdn.ripple.com/wp-content/uploads/2015/01/noripple-04.png
-            "img/noripple-05.png": https://cdn.ripple.com/wp-content/uploads/2015/01/noripple-05.png
-            "img/noripple-06.png": https://cdn.ripple.com/wp-content/uploads/2015/01/noripple-06.png
-            "img/key-address-rels.png": https://cdn.ripple.com/wp-content/uploads/2017/05/key-address-rels.png
-            "img/paychan-flow.png": https://cdn.ripple.com/wp-content/uploads/2017/05/paychan-flow1.png
-            "img/consensus-agreed-transaction-set.png": https://cdn.ripple.com/wp-content/uploads/2014/12/Overview-of-Ripple-Ledger-Consensus-and-Validation-12_12-06.png
-            "img/consensus-calculate-validation.png": https://cdn.ripple.com/wp-content/uploads/2014/12/Overview-of-Ripple-Ledger-Consensus-and-Validation-12_12-07.png
-            "img/consensus-candidate-transaction-sets.png": https://cdn.ripple.com/wp-content/uploads/2014/12/Overview-of-Ripple-Ledger-Consensus-and-Validation-12_12-05.png
-            "img/consensus-declare-validation.png": https://cdn.ripple.com/wp-content/uploads/2014/12/Overview-of-Ripple-Ledger-Consensus-and-Validation-12_12-08.png
-            "img/consensus-validated-ledger.png": https://cdn.ripple.com/wp-content/uploads/2014/12/Overview-of-Ripple-Ledger-Consensus-and-Validation-12_12-09.png
-            "img/xrp-ledger-network.png": https://cdn.ripple.com/wp-content/uploads/2014/12/Overview-of-Ripple-Ledger-Consensus-and-Validation-12_12-04.png
-            "img/escrow-success-flow.png": https://cdn.ripple.com/wp-content/uploads/2017/09/escrow-success-flow.png
-            "img/escrow-cancel-flow.png": https://cdn.ripple.com/wp-content/uploads/2017/09/escrow-cancel-flow.png
-            "img/currency-code-format.png": https://cdn.ripple.com/wp-content/uploads/2017/11/currency-code-format.png
-            "img/currency-number-format.png": https://cdn.ripple.com/wp-content/uploads/2017/11/currency-number-format.png
-            "img/demurrage-currency-code-format.png": https://cdn.ripple.com/wp-content/uploads/2017/11/demurrage-currency-code-format.png
-            "img/xrp-ledger-network-ledger-store-and-shard-store.png": https://cdn.ripple.com/wp-content/uploads/2018/02/xrp-ledger-network-ledger-store-and-shard-store1.png
-
-pages:
-  # I. Introduction ------------------------------------------------------------
-
-    -   md: concept-xrp-ledger-intro.md
-        category: Introduction
-        targets:
-            - local
-            - ripple.com
-
-    # "XRP Ledger Ecosystem Overview" goes here
-
-  # II. Technical Overview -----------------------------------------------------
-
-    -   md: concept-consensus.md
-        category: Technical Overview
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-reaching-consensus.md
-        category: Technical Overview
-        targets:
-            - local
-            - ripple.com
-
-    # "Transaction Processing" goes here (broken off from transaction reference)
-
-    -   md: concept-accounts.md
-        category: Technical Overview
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-cryptographic-keys.md
-        category: Technical Overview
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-fees.md
-        category: Technical Overview
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-fee-voting.md
-        category: Technical Overview
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-amendments.md
-        category: Technical Overview
-        targets:
-            - local
-            - ripple.com
-
-    -   md: reference-amendments.md
-        category: Technical Overview
-        targets:
-            - local
-            - ripple.com
-
-    # III. About XRP -----------------------------------------------------------
-
-    -   md: concept-money.md # TODO: maybe split this up into just an XRP intro?
-        category: About XRP
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-reserves.md
-        category: About XRP
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-transaction-cost.md
-        category: About XRP
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-partial-payments.md
-        category: About XRP
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-escrow.md
-        category: About XRP
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-depositauth.md
-        category: About XRP # Not strictly an XRP feature, but most relevant to XRP
-        targets:
-            - local
-            - ripple.com
-
-    # DOC-696 "About Payment Channels" goes here
-
-  # IV. XRP Tasks --------------------------------------------------------------
-
-    # "Connecting to rippled" goes here (extracted from rippled reference)
-
-    -   md: tutorial-rippleapi-beginners-guide.md
-        category: XRP Tasks
-        targets:
-            - local
-            - ripple.com
-
-    # DOC-1299 "Create an XRP Ledger Account" goes here
-
-    # DOC-1322 "Sending Exact XRP Payments" goes here
-
-    -   md: tutorial-reliable-transaction-submission.md
-        category: XRP Tasks
-        targets:
-            - local
-            - ripple.com
-
-    # "Robustly Monitoring for Payments" goes here (adapted from gateway guide?)
-
-    # "Bouncing Payments" goes here (adapted from gateway guide?)
-
-    -   md: tutorial-multisign.md
-        category: XRP Tasks # This isn't strictly XRP-related though...
-        targets:
-            - local
-            - ripple.com
-
-    -   md: tutorial-escrow.md
-        category: XRP Tasks
-        targets:
-            - local
-            - ripple.com
-
-    -   md: tutorial-paychan.md
-        category: XRP Tasks
-        targets:
-            - local
-            - ripple.com
-
-    -   md: tutorial-regular-keys.md
-        category: XRP Tasks # Not strictly XRP-related, either...
-        targets:
-            - local
-            - ripple.com
-
-  # V. Issued Currencies -------------------------------------------------------
-
-    # TODO: stand-alone issued currencies intro?
-
-    -   md: concept-freeze.md
-        category: Issued Currencies
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-transfer-fees.md
-        category: Issued Currencies
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-noripple.md
-        category: Issued Currencies
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-authorized-trust-lines.md
-        category: Issued Currencies
-        targets:
-            - local
-            - ripple.com
-
-    # DOC-78 "Decentralized Exchange" goes here
-
-    # DOC-844 "TickSize Settings" goes here
-
-    -   md: concept-paths.md
-        category: Issued Currencies
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-checks.md
-        category: Checks
-        targets:
-          - local
-          - ripple.com
-
-    -   md: tutorial-checks-send.md
-        category: Checks
-        targets:
-            - local
-            - ripple.com
-
-    -   md: tutorial-checks-lookup-by-sender.md
-        category: Checks
-        targets:
-            - local
-            - ripple.com
-
-    -   md: tutorial-checks-lookup-by-recipient.md
-        category: Checks
-        targets:
-            - local
-            - ripple.com
-
-    -   md: tutorial-checks-cancel.md
-        category: Checks
-        targets:
-            - local
-            - ripple.com
-
-    -   md: tutorial-checks-cash-exact.md
-        category: Checks
-        targets:
-            - local
-            - ripple.com
-
-    -   md: tutorial-checks-cash-flex.md
-        category: Checks
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-demurrage.md
-        category: Issued Currencies
-        targets:
-            - local
-            - ripple.com
-
-  # VI. The rippled Server -----------------------------------------------------
-
-    -   md: tutorial-rippled-setup.md
-        category: The rippled Server
-        targets:
-            - local
-            - ripple.com
-
-    # -   md: reference-rippled.md # TODO: break out the concept parts for here
-    #     category: The rippled Server
-    #     targets:
-    #         - local
-    #         - ripple.com
-
-    -   md: concept-stand-alone-mode.md
-        category: The rippled Server
-        targets:
-            - local
-            - ripple.com
-
-    -   md: concept-history-sharding.md
-        category: The rippled Server
-        targets:
-            - local
-            - ripple.com
-
-    -   md: tutorial-build-run-rippled-ubuntu.md
-        category: The rippled Server
-        targets:
-            - local
-            - ripple.com
-
-  # VII. The Exchange Business Model -------------------------------------------
-    -   md: tutorial-listing-xrp.md
-        category: The Exchange Business Model
-        targets:
-            - local
-            - ripple.com
-
-  # VIII. The Gateway Business Model -------------------------------------------
-    -   md: concept-issuing-and-operational-addresses.md
-        category: The Gateway Business Model
-        targets:
-            - local
-            - ripple.com
-
-    -   md: tutorial-gateway-guide.md
-        category: The Gateway Business Model
-        targets:
-            - local
-            - ripple.com
-
-    -   md: gb-2015-06.md
-        category: The Gateway Business Model
-        targets:
-            - local
-            - ripple.com
-
-    -   md: gb-2015-05.md
-        category: The Gateway Business Model
-        targets:
-            - local
-            - ripple.com
-
-  # IX. Reference Material
-    -   md: reference-rippled.md
-        category: Reference Material
-        targets:
-            - local
-            - ripple.com
-
-    -   md: reference-currency.md
-        category: Reference Material
-        targets:
-            - local
-            - ripple.com
-
-    -   md: reference-transaction-format.md
-        category: Reference Material
-        targets:
-            - local
-            - ripple.com
-
-    -   md: reference-ledger-format.md
-        category: Reference Material
-        targets:
-            - local
-            - ripple.com
-
-    -   name: RippleAPI Reference # name is required for remote-sourced files
-        md: https://raw.githubusercontent.com/ripple/ripple-lib/0.19.1/docs/index.md
-        html: reference-rippleapi.html
-        category: Reference Material
-        filters:
-            - remove_doctoc
-            - add_version
-        targets:
-            - local
-            - ripple.com
-
-    -   md: reference-data-api.md
-        category: Reference Material
-        targets:
-            - local
-            - ripple.com
-
-  # Appendix: API Tools --------------------------------------------------------
-    -   name: RPC Tool
-        category: API Tools
-        html: xrp-ledger-rpc-tool.html
-        targets:
-            - local
-        template: template-xrp-ledger-rpc-tool.html
-
-    -   name: WebSocket API Tool
-        category: API Tools
-        html: ripple-api-tool.html
-        sidebar: custom
-        targets:
-            - local
-        template: template-ripple-api-tool.html
-
-    -   name: Data API v2 Tool
-        category: API Tools
-        html: data-api-v2-tool.html
-        methods_js: js/apitool-methods-data_v2.js
-        rest_host: https://data.ripple.com
-        doc_page: reference-data-api.html
-        sidebar: custom
-        targets:
-            - local
-        template: template-rest-api-tool.html
-
-    -   name: ripple.txt Validator
-        category: API Tools
-        html: ripple-txt-validator.html
-        targets:
-            - local
-        template: template-ripple-txt-validator.html
-
-    -   name: XRP Test Net Faucet
-        category: API Tools
-        html: xrp-test-net-faucet.html
-        targets:
-            - local
-        template: template-test-net.html
-
-  # Non-canonical pages
-    -   name: Page Manifest
-        # Used to inform the ripple.com code what pages it should map
-        html: devportal-manifest.php
-        template: template-manifest.php
-        targets:
-            - ripple.com
-
-# Link Checker Config ------------------------------------------------------- #
-
-ignore_anchors_in:
-    - data-api-v2-tool.html
-    - ripple-api-tool.html
-    - tool-jsonrpc.html
-
-#Sometimes, a link is not really problematic, but the link checker detects it
-# as such and the easiest solution is to ignore it.
-known_broken_links:
-    # Strangely, Python doesn't like the cert here. Firefox is OK with it.
-    - https://validators.ripple.com
-
-    # Login required for the client portal.
-    - https://clients.ripple.com/
-
-    # These PDFs download OK in a browser
-    - http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32015R0847
-    - http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:345:0001:0009:EN:PDF
-
-# Style Checker Config ------------------------------------------------------ #
-
-word_substitutions_file: tool/word_substitutions.yaml
-phrase_substitutions_file: tool/phrase_substitutions.yaml

tool/template-contentonly.html

@@ -1,3 +0,0 @@
-<div class="content">
-{{ content }}
-</div>

tool/template-contentwithtoc.html

@@ -1,12 +0,0 @@
-<div class='devportal_wrapper'>
-  <aside class='sidebar' role='complementary'>
-    <ul class='dev_nav_sidebar' id='dactyl_toc_sidebar'>
-        {{ sidebar_content }}
-    </ul>
-  </aside>
-  <main class='main' role='main'>
-    <div class='content'>
-      {{ content }}
-    </div>
-  </main>
-</div>

tool/template-home.html

@@ -206,8 +206,7 @@
       <h2>Built on the XRP Ledger</h2>
       <div class="blurb">
           <p>Learn about just a few of the types of integrations developers have built on the XRP Ledger.</p>
-          <p>Get updates about XRP Ledger use cases, webinars, and releases. <a class="btn btn-secondary ml-3" href="http
+          <p>Get updates about XRP Ledger use cases, webinars, and releases. <a class="btn btn-secondary ml-3" href="https://goo.gl/forms/sHMFxU8dKiTUaltE3">Sign up! <i class="fa fa-external-link" aria-hidden="true"></i></a></p></p>
-s://goo.gl/forms/sHMFxU8dKiTUaltE3">Sign up! <i class="fa fa-external-link" aria-hidden="true"></i></a></p></p>
       </div>
 
       <div class="container">

tool/template-landing-docs.html

@@ -46,7 +46,7 @@
               <ul>
                 <li><a href="websocket-api-tool.html">Make a call to the rippled API</a></li>
                 <li><a href="xrp-test-net-faucet.html">Access the XRP Ledger Test Net</a></li>
-                <li><a href="landing-concepts.html">Understand XRP Ledger Concepts</a></li>
+                <li><a href="concepts.html">Understand XRP Ledger Concepts</a></li>
               </ul>
             </div><!--/.curated-links-->
           </div><!--/.card-body-->
@@ -62,7 +62,7 @@
                 <li><a href="public-rippled-methods.html">rippled API Public Methods Reference</a></li>
                 <li><a href="accounts.html">Accounts</a></li>
                 <li><a href="install-rippled.html">Install rippled</a></li>
-                <li><a href="reference-rippleapi.html">RippleAPI for JavaScript Reference</a></li>
+                <li><a href="rippleapi-reference.html">RippleAPI for JavaScript Reference</a></li>
               </ol>
             </div><!--/.curated-links-->
           </div><!--/.card-body-->

tool/template-manifest.php

@@ -1,12 +0,0 @@
-<?php
-
-$devPortalPages = array(
-  {% for page_filename, page_url in target.link_subs.items() %}
-    {% set wp_page_id = page_url[:-1]|replace("https://ripple.com/build/", "") %}
-    {% if "/" not in wp_page_id and "-tool" not in wp_page_id %}
-  '{{wp_page_id}}'  => '{{page_filename}}',
-    {% endif %}
-  {% endfor %}
-);
-
-?>