28 Oct 2026 · 5 min read · Yüz Medya · Updated 13 Nov 2026
A Laravel admin panel for a content team
An admin panel is not the screen a developer finds comfortable. It is the screen a content team can update without breaking the site. Few fields, a clear status, a preview.
A Laravel admin panel for a content team is not a table of the whole database. It is the heading, the text, the image and the publish button the team will change this week. A field that helps a developer, left on the editor’s screen, makes the panel frightening. A frightened team writes the text to the agency and waits. The point of the panel is to end that wait. The site is updated in the owner’s hands.
At Yuz Medya we build the panel by content type. A service page, an article, a notice and a person do not share one form. Each type has a few required fields. A field that is not required is hidden, or sits behind “advanced”. In the first version the advanced section often stays closed. A section that is never opened is removed in the second version. We think about this simplification together with the reason for custom software. We set that reason in when a business needs custom Laravel software.
Status, draft and live
A piece of content is a draft, or it is live, or it has been taken down. A third status of “almost ready” can live in speech inside the team. It should not live in the panel. A draft is invisible on the site. A preview shows how it will look before it is published. Without a preview, the editor publishes to be sure, and then regrets it. Regret is how a panel stops being used.
Preview and language
On a bilingual site each language has its own draft. Turkish can be live while English stays in draft. The language switch does not force a visit to a page whose translation is unfinished. The panel lists the missing language. Without the list, the missing page appears in the menu as an empty door. Information architecture rejects that door too. The panel makes the rejection a daily job. The page itself stays live as a corporate website. The panel is the kitchen of the launch.
Limits on images and headings
An image arrives in the panel with a warning on size and crop. A huge file is not uploaded on the promise that “the site will shrink it”. If a heading is long enough to overflow the first screen, the panel warns. It does not have to forbid the save. The warning stands in for training. Training happens once. The warning stays on every save. The media library should not fill with ten copies of the same image. Copies tire both the speed and the editor.
Permission comes before the delete button
An editor edits their own content. They cannot delete someone else’s live page in one click. An admin sees delete and the opening of users. The split reduces accidents. It does not end them. That is why deleted content sits in a bin for a while and can be restored. Without restore, one wrong click takes a service page offline. The detail of permission stays on the developer screen. The editor does not memorise role names. The button they see is their permission.
Maintenance is part of the panel too. An update should not lock the screen during the hour the editor writes. A backup is taken before a release. We describe that rhythm on the WordPress side in a maintenance routine. The same sentence holds for a Laravel panel: if the kitchen falls apart, the window keeps the old text. WordPress / PHP software does not hand over the panel and disappear. In the first month, the field the editor gets stuck on is simplified.
Handover is a task list
On handover day the editor should be able to do three jobs without the agency: open a draft, change an image, publish. Those three are explained in a short video or a short page. A panel that is not explained stays dependent on the agency even if the software is custom. Dependence is the panel’s failure.
- Few fields: as many as the type needs, not as many as the developer finds comfortable.
- Status: draft, live, taken down.
- Preview: see it before publishing.
- Restore: deleted content sits in a bin for a while.
Once a quarter the panel is read together with fields nobody uses. An unused field comes out. A question the editor asks every week is written beside the field as one sentence of help. The help text stands in for the meeting. A meeting is needed only when the flow changes.
Frequently asked questions
Should an editor know HTML?
No. Heading, paragraph, list and image are enough. A free HTML field is the shortest way to break the layout. If a special block is needed, it is added as a named component, not as raw code. The editor’s job is the sentence. The layout lives in the component.
Can the panel be used from a phone?
Basic actions, such as taking an urgent notice offline, can be done on a phone. Long text and image crops produce fewer mistakes on a desktop. The panel should not fall apart on a phone. The main production screen is a wide one. Both use the same permission.
How does old content enter the panel?
By type, and cleaned. Not every old page is moved one-to-one into the new form. A field that is not moved does not return as “please fill this in too”. When the move is finished, the old admin address closes. If two panels stay open, content goes stale in one and new in the other. There is one kitchen.
Related services