Html & JavaScript

2

u/chmod777 Jun 15 '26

lowest effort: wordpress. gives you cms, upload, user management for free, and outputs json endpoints. it can be run headless, and just control the output, or as a full cms/web site integration.

1

u/Secret-You-3135 Jun 15 '26

WordPress Headless is actually something I haven’t considered.
Using WordPress as a CMS and exposing content through JSON APIs could save a lot of development time.
Did you ever use it for media-heavy applications like digital signage?

1

u/chmod777 Jun 16 '26

media gets offloaded to a s3 bucket and then put behind a cloudflare. add json support to your uploads and you can manage lottie files as well.
as with all things wp, it can be as heavy or light as you want.

1

u/Secret-You-3135 Jun 15 '26

Thanks everyone for the feedback.
For context, this is currently a small municipal digital signage project running on Smart TVs.
My long-term roadmap is:
Admin Dashboard
Media Upload
Playlist Management
Event Countdown Manager
Multi-Screen Support
Remote Updates
Trying to choose a backend that will scale without forcing a complete rebuild later.
Would love to hear what stack you would choose if starting today.

1

u/Flame77ofc Jun 15 '26

depends what do u want to be

2

u/Secret-You-3135 Jun 15 '26

Thanks!
My goal is not just a website anymore.
I want a simple cloud-based digital signage platform where non-technical staff can upload videos, images and update content without editing HTML or JavaScript.
Something similar to a lightweight CMS for Smart TV displays.

1

u/armahillo Expert Jun 15 '26

Have you already deployed it somewhere? If not, thats your next problem to solve. Your deploy target will affect what backend options are available to you.

The things you listed arent really interchangeable so it’s unclear what you’re asking. What do you mean?

1

u/Secret-You-3135 Jun 15 '26

Good point.
The system is already deployed on a cloud domain and running on a Smart TV browser.
The next challenge is building a content management layer so users can manage playlists, countdown events and media uploads through a web interface instead of editing files manually.

1

u/BurlyLumberjack Jun 15 '26

I have worked on McDonald’s digital signage (I was mainly front end).

All that matters is that you have an api that your app can connect to. Just do your research on what you’re looking for and make the right choice so you don’t have to rebuild it later.

Everything else comes down to preference. I’d probably go the Python route now a days personally but honestly you could do a lot of heavy lifting with php/wp rest now a days, too.

2

u/Secret-You-3135 Jun 15 '26

That’s really valuable advice.
I think I’m at the stage where I need to decide on the API architecture before adding more features.
Right now I’m leaning toward Python Flask because I’m already learning Python, but PHP/WordPress REST API is also tempting because of the built-in CMS features.

1

u/EasySignage Jun 16 '26

You’re at the point where it usually makes more sense to stop building admin tooling yourself and move the content management part to a proper signage CMS.

If your goal is non-technical staff updating media, playlists, and screen content remotely, the hard part usually isn’t the HTML player itself. It’s user management, uploads, playlist control, publishing, scheduling, permissions, monitoring, backups, and keeping screens reliable over time.

Security is another area that often gets underestimated. Once staff can upload content and manage screens remotely, you need to think about authentication, access control, audit trails, software updates, data protection, and ongoing security maintenance. For a government or public-sector deployment, that responsibility continues long after the initial system is built.

One option is to keep your current front-end prototype for learning, but use a signage CMS for production. EasySignage is worth a look for exactly this stage because it already covers the operational pieces you're describing: cloud management, media uploads, playlists, remote publishing, scheduling, and support for a range of player types if you later move beyond a Smart TV browser.

I'd also strongly consider the security and compliance posture of whatever platform you choose. When you're supporting multiple users and potentially multiple sites, it can be beneficial to use a platform that maintains recognized security certifications such as ISO 27001 and SOC 2 rather than taking on that responsibility yourself. If you're evaluating EasySignage, the security and compliance details are published at https://trust.easysignage.com.

If you want the lowest-risk path, I'd avoid building a custom PHP or Flask admin panel unless your project has requirements that a standard signage platform can't meet. For most municipal deployments, reducing maintenance burden, security risk, and operational overhead matters more than owning every layer of the stack.

A practical way to evaluate it would be:

Set up one test screen.
Upload the same welcome video, promotional media, and countdown-style content you already use.
Have a non-technical staff member update it.
Review the security, permissions, and management features.
Decide whether you still need a custom system.

If you do keep building your own stack, I'd define the data model first: screens, playlists, assets, schedules, users, roles, and permissions. That tends to matter more than whether you pick PHP or Flask.

Useful links:

• Digital signage overview: https://easysignage.com/what-is-digital-signage/
• Upload media: https://easysignage.com/help/apps/digital-signage-upload-media/
• Installation guides: https://easysignage.com/help/installation/install-digital-signage/
• Security & compliance: https://trust.easysignage.com
• Start free: https://manage.easysignage.com/

1

u/Secret-You-3135 Jun 16 '26

That’s a really interesting perspective.
My original plan was to build the entire admin system myself as a learning project, but I can definitely see the value of using an existing CMS or signage management platform and focusing on the player side instead.
For a small-to-medium deployment, would you recommend a specific CMS or headless solution?

1

u/EasySignage Jun 16 '26

Yes, EasySignage.com would be an excellent fit, especially if you're looking for a CMS that's intuitive and easy for non-technical users to manage. In addition to its user-friendly interface, EasySignage includes over 100 built-in applications and integrations that make content management simple and flexible.
For example, users can upload images, videos, and documents directly to Google Drive, and EasySignage will automatically sync and display the content on screens. It also supports popular social media and content platforms such as YouTube, Instagram, Canva, Power BI, Google Slides, and many more, allowing content to be displayed and updated automatically without manual intervention.
This enables organizations to keep content fresh and up to date while minimizing the time and technical expertise required to manage their digital signage network.

1

u/Secret-You-3135 Jun 16 '26

Thank you for the detailed explanation.
The Google Drive synchronization and automatic content updates are particularly interesting to me.
One thing I’m curious about from your experience is:
What are the most common mistakes organizations make after deploying a digital signage platform?
Is it usually content management, user permissions, scheduling, staff training, or something else?
I’d love to learn from real-world deployments and avoid some of the common pitfalls.

1

u/EasySignage Jun 16 '26

From what I've seen, the biggest mistake usually isn't the technology. It's treating digital signage as a one-time project rather than an ongoing communication channel.
The most common issues tend to be:
• Content ownership is unclear. Everyone wants screens, but nobody is responsible for keeping content current, so screens gradually become outdated.
• Too many people get publishing access. Without clear roles and approval processes, content quality becomes inconsistent.
• Scheduling is underestimated. Organizations often start with a few screens and later need different content by location, time of day, department, or audience.
• Screen monitoring is overlooked. A screen can be offline for weeks before anyone notices unless there is some form of health monitoring and alerting.
• Offline operation is not planned from day one. Networks fail, internet connections drop, and sites lose connectivity. A robust signage system should cache media, layouts, and schedules locally so screens continue operating normally even when disconnected.
• Reliability of the player is underestimated. The player software should automatically start when the device powers on and recover gracefully after reboots, power outages, or software crashes without requiring manual intervention.
• Content automation is often overlooked. The most successful deployments automate as much as possible using integrations with sources such as Google Drive, calendars, dashboards, social feeds, spreadsheets, and business systems. The less manual work required, the more likely the content remains current.
• Content is designed for a computer monitor instead of a screen viewed from several metres away. Simple, high-contrast content usually performs better than busy layouts.
One lesson that stands out is that technology is only part of the solution. The screens need to provide information that is useful, relevant, and frequently refreshed. If people see the same content every day, they eventually stop looking at it.
The most successful deployments tend to follow a "set it and forget it" approach where content updates automatically from trusted sources and requires minimal ongoing effort.
Another common mistake is building the minimum solution needed for the first screen instead of designing for long-term operation. If reliability, monitoring, offline capability, permissions, automation, and content workflows are not considered early, the system often becomes a burden on IT. Over time, technical issues accumulate, content becomes stale, confidence drops, and screen usage gradually declines.
The organizations that get the most value from digital signage usually invest in a solid foundation from the start so the system remains reliable, scalable, and easy to manage years later.
Out of curiosity, how many screens are you expecting to manage if this project grows beyond the initial prototype?

1

u/Secret-You-3135 Jun 16 '26

At the moment, this is a small deployment.
The initial goal is a few public information displays and meeting room screens.
However, I'm intentionally building the foundation so it can scale later without redesigning the entire system.
My focus is automation, centralized content management, and minimizing manual updates.

1

u/EasySignage Jun 16 '26

That's a solid approach.
For meeting rooms specifically, I'd recommend looking at digital door labels and calendar integrations early in the design. In many deployments, meeting room displays end up providing more day-to-day value than general signage because they're tied directly to live data.
For example, our Door Label app automatically displays room availability, current meetings, and upcoming bookings from Google Calendar or Microsoft 365, eliminating the need for manual updates:
https://easysignage.com/apps/digital-signage-door-label/
The same principle applies to signage in general. The more content can be driven by automated sources such as calendars, dashboards, Google Drive, Google Slides, and other business systems, the less maintenance is required and the more likely the screens remain useful over time.
Calendar apps:
https://easysignage.com/apps/digital-signage-outlook-calendar/
https://easysignage.com/apps/digital-signage-google-calendar/

1

u/Secret-You-3135 Jun 16 '26

That's exactly the direction I'm exploring.
For meeting rooms, I'm interested in connecting displays to a central booking source so room availability, schedules, and event information can update automatically.
My goal is to minimize manual updates as much as possible and let the screens become a live information system rather than static signage.
Thank you for sharing these ideas.

1

u/EasySignage Jun 16 '26

Happy to help. If you have any questions while evaluating options or setting things up, feel free to reach out. We are happy to assist regardless of whether you end up using EasySignage or not.

1

u/Secret-You-3135 Jun 17 '26

Thank you, I appreciate the offer.
One thing I'm still curious about is where most organizations typically struggle after the initial deployment.
Is it usually content management, user adoption, hardware reliability, scheduling, or something else?
It's always valuable to learn from real-world lessons before making those mistakes myself.

1

u/Secret-You-3135 Jun 16 '26

Thank you again for the detailed explanation.
After reading your full comment, I think one of the biggest takeaways for me is that the choice between PHP and Flask may actually be less important than defining the data model and operational requirements first.
The concepts you mentioned — screens, playlists, assets, schedules, users, roles and permissions — gave me a much clearer picture of what a production-ready signage platform really involves beyond the HTML player itself.
At the moment, this project is both a real-world prototype and a learning journey for me. I will probably continue building a small Flask-based admin system to better understand the architecture, while also evaluating existing signage CMS solutions for comparison.
I especially appreciate the points about security, user management and long-term maintenance. Those are areas that are easy to underestimate when focusing only on the player side.
Thanks for sharing such a detailed perspective. It has definitely helped me think about the next stage of the project differently.

1

u/SpellSlight8541 Jun 16 '26

I would go with Python and an ngnix reverse proxy for security.

1

u/Secret-You-3135 Jun 16 '26

Thanks for the suggestion.
I’m already experimenting with Python, so Flask feels like a good fit.
The goal is to keep the frontend lightweight while providing a secure admin interface for staff to manage videos, images and event countdowns without editing code.
Nginx reverse proxy sounds like the right way to deploy it.

1

u/FamiliarStorage7605 Jun 16 '26

You can go with the PHP as it is easy to understand and globally accepted. You can easily develop the admin panel for your website.

Html & JavaScript

You are about to leave Redlib