Quirks

Things you might not expect

/api/user

• When registering a new user (with a username, password, email), usually you get a user object back. IF the system is set to "Instant" user confirmation, you still get a user, but the special field is temporarily set to the login token. You can thus check for whether the special field is non-empty, and skip to logging the user in and being fully done with registration
• Furthermore, if the system is set to "Instant" confirmation, the two confirmation code endpoints (sendregistrationcode and confirmregistration) are disabled, and you will get Forbidden http errors.

/api/live/ws

• As explained on the https://github.com/randomouscrap98/contentapi/wiki/Errors page, critical errors will override your websocket request type (such as ping, request, setuserlist, etc) and close the websocket, BUT, non-critical errors are only indicated by filling out the error field. As such, if your websocket message handler assumes that any response with the proper type is valid, you will run into issues. You should check the error field, and if it's not empty, the result was an error.

objects

• Many objects from the database are not fully deleted, and leave behind markers you can and will pick up in result sets, unless you filter them. message, content, and user are the main ones, basically anything with a deleted field. Deleted content is stripped of all information except the id and organizational data (like the contentId or parentId). If you do not want to see deleted objects, you can add the !notdeleted() macro to your searches.
• Speaking of deleted, you cannot delete anything by setting the deleted field, it is always readonly. Please use the deletion endpoints
• Legacy data: For messages (comments), older comments may have the editDate field set even if they are not edited. For newer comments, that field is set to null. Do not depend on the editDate to determine the edit status, simply look at edited, which is a boolean.

/api/file

• When uploading a file, it's one of the only endpoints with form data. As such, everything should be a string, so you could set "true" or "false" for boolean values, and "1" or "128" for integer values.
• Also on upload, the values option is a dictionary of key/value pairs, but unlike content, the upload endpoint ONLY accepts string values. If you need to set integer or boolean values and have them be typed properly, you'll need to modify the file data afterwards.
  • To set a value, you may do something like: form.append("values[bucket]", bucket.value);. The key here is bucket, and notice the value is not json encoded, because it always expects a string anyway.

Activity

• Currently, querying activity gives all events in the system, including stuff like file creates and all events for deleted pages (which means you won't be able to get the title of the page to display for the events). You may (probably) not want this, so there is a !basichistory() macro you can use to filter out files and activity on deleted content. Just keep in mind that querying activity without this macro will get you a lot of junk
• UNFORTUNATELY, you can't rely on the ids of activity to determine the order, because of an oversight during conversion. If you're going to order activity, it HAS to be by the date field!