Social Media Picker and Online Scheduler | Case Study

A desktop-first workflow for preparing photography posts, generating or polishing captions, scheduling them locally or online, and publishing to multiple social platforms with operational checks.

Scope note: this page documents the implemented workflow and verified behavior. It intentionally does not publish API tokens, SMTP secrets, full source files, or credential-bearing configuration.

0. Section Map

• 1: Problem context and objective.
• 2: Workflow logic from image selection to posting.
• 3: Local scheduler architecture.
• 4: Online scheduler architecture.
• 5: Platform rules, split posting, and X boundary.
• 6: Reliability handling: partial runs, fatal errors, email summaries, and cleanup.
• 7: UI evidence from the implemented tool.
• 8: Code exposure decision for a public case study.

1. Problem Context And Objective

Posting photography sets manually across several platforms creates repeated work and repeated risk: captions can drift, platform selections can be missed, schedules depend on the computer being on, and partial failures are hard to track cleanly.

Objective: keep the creative review step manual, but automate the repetitive operational work around scheduling, publishing, logging, email reporting, and cleanup.

• Prepare a single post queue from selected source images.
• Generate, regenerate, polish, or manually edit captions before scheduling.
• Post the same approved content at the same scheduled time across selected platforms.
• Keep history and restore controls so drafts and posted records remain traceable.
• Support both local Windows scheduling and online cron scheduling.

2. Workflow Logic

The workflow is deliberately staged. The tool does not immediately post from a folder scan. It first builds a reviewed Post 1 queue, then saves a scheduled record with captions, selected platforms, image references, and status fields.

1. Select a source folder and move images into the Post 1 queue.
2. Review the preview and file order.
3. Generate or polish the all-platform caption and X caption.
4. Choose date, time, Instagram preparation mode, and platforms.
5. Schedule locally or export to the online scheduler.
6. Runner processes due jobs and records per-platform results.
7. Email summary is sent after processing.
8. Fully posted online jobs are archived and temporary online media is removed.

3. Local Scheduler Architecture

The local workflow keeps the full desktop experience available through the Social Media Picker and a Windows scheduled task.

• UI: social_media_picker.py, a Tkinter desktop application.
• Runner: autopost_runner.py, used by the local AutoPost task.
• History: social_media_history.db, used for saved sessions, scheduled records, posted records, and restore flows.
• Launcher: Social Media Picker.vbs, used to open the app without the extra PowerShell window.
• Email settings: SMTP settings are read from mail_secrets.php outside the public case-study content.

Confirmed local behavior includes session save/restore, history view, caption generation, ChatGPT polish, scheduled posting, and HTML email summaries after post runs.

4. Online Scheduler Architecture

The online scheduler removes the requirement that the local computer stays on at the posting time. The desktop app exports a queue package, uploads it by FTP, and a Hostinger PHP cron processes due items.

• Online runner: cron.php under the online social_autopost folder.
• Queue format: one JSON file per scheduled post under data/queue.
• Timezone: scheduled entries carry Europe/Amsterdam.
• Notifications: online SMTP summaries are sent to contact@amir2000.nl.
• Cleanup: posted queue JSON moves to data/archive/posted and temporary media/post_ID folders are removed.
• Access control: public browsing of scheduler internals is blocked with .htaccess rules.

The online queue carries only the operational data needed for the run: schedule time, timezone, selected platforms, captions, media references, source references, and platform results.

{
  "id": "post_ID",
  "local_post_id": 0,
  "status": "scheduled",
  "scheduled_for": "YYYY-MM-DD HH:MM",
  "timezone": "Europe/Amsterdam",
  "platforms": ["FB Page", "Instagram", "Threads", "Tumblr", "Mastodon"],
  "media": [
    {
      "filename": "image.jpg",
      "relative_path": "media/post_ID/image.jpg",
      "public_url": "https://www.amir2000.nl/..."
    }
  ],
  "platform_results": {}
}

5. Platform Rules And Boundaries

The confirmed auto-post targets are FB Page, Instagram, Threads, Tumblr, and Mastodon. X remains visible in the UI but intentionally unchecked and disabled for auto-posting because automated posting requires paid API access.

• FB Page: posts through the configured page token flow.
• Instagram: uses container creation, readiness wait, then publish.
• Threads: uses Threads API container/publish flow.
• Tumblr: uses Tumblr API posting and can be retried after transient failures.
• Mastodon: uploads media and posts status through the configured instance.

Split rules currently implemented:

• Instagram: up to 10 images per post.
• Threads: up to 20 images per post.
• Mastodon: up to 4 images per post, so larger sets are split into numbered parts.
• X: split limit exists in code, but X auto-posting is disabled.

6. Reliability And Failure Handling

The scheduler treats every platform result separately instead of assuming that a post is all-or-nothing. This matters because real platform APIs can return transient failures or token/authentication errors.

• Partial runs: already successful platforms are kept; unfinished or retryable work can be retried.
• Fatal Meta errors: expired or unrecoverable Meta token failures are marked as needs_attention so the scheduler does not retry forever.
• Tumblr retry example: a confirmed online run became partial first, then completed successfully on the next cron pass.
• Email summaries: each run can produce an HTML email summary with platform-level results.
• Cleanup discipline: online cleanup happens after posted status, moving JSON to archive and removing temporary media.

A confirmed 18:00 online run posted successfully to all selected targets after a second cron pass for Tumblr. The final cron state archived the posted JSON and removed the matching online media folder.

7. UI Evidence

The interface screenshots below show the main operating surface, the date/time picker, and the online scheduling path.

8. Code Exposure Decision

This public case study should not include the full code. The full implementation contains configuration paths, platform integration details, and operational wiring that should stay private or be shared only in a cleaned repository.

Best public approach:

• Show architecture and data flow.
• Show selected sanitized snippets such as queue JSON shape or function responsibilities.
• Name the important files and modules.
• Explain failure handling, retry strategy, and cleanup rules.
• Keep credentials, tokens, SMTP config, and full source files out of the public page.

9. Outcome

• One reviewed post can be scheduled for multiple platforms with the same approved content.
• Local scheduling works through the Windows AutoPost task.
• Online scheduling works through Hostinger cron when the local computer is off.
• Email summaries report success, partial, or attention states.
• Successful online posts are archived and temporary online media is cleaned up.

Known boundary: caption quality tuning remains an improvement area, and X auto-posting is intentionally disabled because of paid API access requirements.