DAMLA — Social auto-poster and scheduler for XenForo 2.0.1

A fix release. Before announcing 2.0.0 we audited the package exactly as it was shipped and found problems that should not wait, so here they are, fixed. If you installed 2.0.0, please upgrade.

Secrets and privacy

• Secrets no longer end up in XenForo's logs. Bot tokens, webhook addresses, app secrets and the licence key you typed into Damla's admin pages were stored in plain text in XenForo's admin log (and in the error log when something failed), because XenForo only hides fields whose name contains "password". 1.0.3 did the same. They are now masked, and the upgrade masks the entries already there.
• Webhook addresses are treated as the secrets they are. For Zapier, Make, n8n and similar receivers the address itself is the password. It is now stored encrypted; admin screens, alerts and emails never show the full address, at most its server, and it is kept out of error details. The channel form no longer shows the saved address: leave the box empty to keep it, or paste a new one to replace it. Channels that were named after their address are renamed to the server name, and the upgrade also removes the address from earlier queue errors and alerts. (If the upgrade cannot use Damla's encryption key, because the key file is missing or is not the key your saved connections were encrypted with, the address is left unencrypted. XenForo's server error log gives that webhook channel's ID number; once Diagnostics shows the key working, open that channel and save it; the address box can stay empty.)
• Text sent back by a service (for example a Mastodon server's error message) is shown as plain text in the admin control panel, never as HTML. The queue links to a sent post only when the service returned a normal web address.
• An authorisation reply from a service is accepted only in the browser session that started the connection, so finish connecting a service in the same browser.
• Social posts now take text only from XenForo's own BB codes. Text inside any other BB code is left out: add-on codes such as hide or members-only, and also custom BB codes you created yourself. Quoted text no longer carries spoilers, @mentions or raw BB code.
• A webhook no longer follows a redirect to another server. If a webhook channel reports that it was redirected, paste the endpoint's current address into the channel.
• Prizma items marked NSFW are not posted, and NSFW pictures are left out of collections.
• Flickr's raw response in the queue no longer contains the app's API key, and the upgrade removes it from responses saved by 2.0.0. The message of an unexpected error, on any service, is now also cleaned before it is saved on a queue row: web addresses are cut back to their server and the account's saved secrets are removed.

Posts that never went out, or went out twice

• Threads and resources with a link on its own line are now posted. XenForo stores a link pasted on its own line as a rich preview (on by default), and Damla's text converter failed on it: the item was never posted (only XenForo's error log recorded why), and "Share to channels" showed an error page. Every earlier Damla version had this problem.
• New threads and gallery items with pictures now reach Instagram, Pinterest and Flickr. In 2.0.0 the rule ran before XenForo had attached the pictures, so these were skipped as "no image".
• No blind resend when the outcome is unknown. If a service does not answer after Damla's request has left, or answers with a server error such as 500, 502 or 504, the post may already be live. On services that cannot reliably recognise a repeat (Telegram, Discord, Slack, Facebook, Tumblr, Pinterest, and Mastodon, whose protection lasts only an hour) Damla no longer sends it again: the post is marked "may already be live", you get an alert (at most one per channel every six hours), and you decide. Where Damla can find the earlier copy (Bluesky, Flickr, Instagram, LinkedIn, Reddit, Threads, WordPress) it keeps retrying on its own; Bluesky posts now get a fixed record key, so a retry finds the first post instead of making a second one. Webhooks also keep retrying, with the same X-Damla-Delivery header on every attempt: your receiver has to ignore a delivery value it has already processed, or it can get the post twice.
• A post whose sending was interrupted (the server stopped the job mid-send) is no longer sent again automatically. It is marked "may already be live", with an alert. A post whose job kept stopping before it ever reached the service is closed with that reason and an alert, and can be retried like any other failed post.
• Uploading the new files before pressing Upgrade is safe. Damla sends nothing until the upgrade has run, so nothing goes out twice, and threads, gallery items and resources created in that time are picked up once the upgrade is done. Until then "Share to channels" and the queue's retry, undo and approve buttons ask you to finish the upgrade first.
• "Share to channels" now replaces an automatic post still waiting for the same thread and channel instead of adding a second one. Channels that already have the thread are listed separately; tick one there only if you want it posted again.
• Before an automatic post goes back out through Undo (after "Cancel everything waiting"), "Try the failed ones again", Retry or Approve, Damla checks whether its content has already reached that channel another way. If it has, the post is marked "already shared" instead of being sent.
• The channel's "Send a test post" can no longer go out twice.
• "Try the failed ones again" now leaves out posts that may already be live, tells you how many and links to them, so you can check each one on the service and retry it from its own row.
• A post that is already with the service (waiting to be published on Instagram or Threads, or a large photo Flickr is still processing) can no longer be cancelled from the queue.
• Visibility and opt-out are read fresh for every send, so content that becomes private during a long background run is no longer posted with an out-of-date answer.
• XFRM "new version" posts now say which version was released and link to it, and "update" posts use the update's own title, text and link (with the version number when a version was released together with the update), instead of repeating the original announcement. A new version and an update posted together from the same form become one post. New placeholder: {version}.

Things that did not work

• Prizma collections are now posted. In 2.0.0 a collection rule could be created but never fired. Public collections are now checked about every ten minutes. When a collection has been left unchanged for 30 minutes, holds at least the rule's minimum number of pictures (two by default) and was created after Damla's first check with the rule switched on, it goes to your approval queue: collection rules always wait for your approval. Switching a rule on never posts old collections, and a collection you rejected does not come back when it changes.
• "Cancel everything waiting" can now really be undone: an Undo button stays on the queue for 24 hours.
• "Retry in the next free slot" works.
• A retried Instagram, Threads or Flickr post gets a fresh wait for the service instead of timing out at once.
• Deleting a channel no longer leaves its held posts in the queue forever; posts that were already on their way are marked "may already be live".
• Without a licence key, only one rule runs in total: the first active rule in your rule list, matching the count on the Licence page. Before, one rule per content type ran, so after upgrading a second rule (for example a gallery rule next to a thread rule) stops posting until you add a licence. Rules that share a display order are now listed in the order they were created instead of by title, so the rule at the top is the one that runs.

Encryption key

• Damla no longer quietly creates a new encryption key when the old one is missing, for example after restoring a backup without the internal_data folder. Diagnostics now says the key is missing and how many saved credentials depend on it; you choose between restoring the file and creating a new key there. After a new key, services can be connected again as usual (Mastodon could not be).
• Diagnostics and the Damla dashboard also warn when some saved credentials were encrypted with a different key: restore the original key file or connect those services again. Keep internal_data/erkan_damla/key.php in your backups.

Uninstall

• Uninstalling Damla no longer recounts every tag and reaction on the board.

Upgrading
Upload the files and run the upgrade as usual. If you are still on 1.0.3, upgrade straight to 2.0.1: it includes everything in 2.0.0. The upgrade masks the Damla secrets already stored in XenForo's admin and error logs (the entries themselves stay); on a large log this step runs in several passes. Database backups taken before this upgrade still contain those entries: if such a backup may have been seen by others, replace the bot tokens, app secrets and webhook addresses it could contain. If you imported a Damla language pack with 1.0.3 or 2.0.0, import it again with "Overwrite language": the updated packs are in the zip under upload/src/addons/Erkan/Damla/translations/.