#KnowledgeBase #KBArticles #PHPMySQL #ITSupport #Troubleshooting #DatabaseManagement #WebDevelopment #KBAdmin #ContentManagement #TechDocumentation #ITBestPractices
A common issue in custom Knowledge Base (KB) systems is a mismatch between articles visible in the database and articles displayed on the public KB pages. This typically occurs due to visibility flags, publishing states, or filtering logic applied at the application layer.
This Knowledge Base article documents a real-world troubleshooting case where newly created KB articles appeared in SQL but were not visible on the public KB pagesβand explains how to identify the root cause, apply the correct fix, and prevent recurrence.
Newly created KB articles are visible in the database (SQL/phpMyAdmin)
Article IDs increment correctly (e.g., 429, 430)
Articles do not appear on the public Knowledge Base pages
No SQL errors or PHP errors are reported
Most KB systems do not display all database records by default. Instead, frontend queries filter articles based on one or more internal flags such as:
Publish status
Visibility type
Article state (draft, public, internal)
Special or system markers
In this specific KB schema, article visibility is controlled by the column:
type ENUM('0','1','2')
Despite the confusing name, this column determines whether an article is public or hidden.
Based on observed system behavior:
type Value | Meaning |
|---|---|
0 | β Published / Public (Visible on KB) |
1 | β Hidden / Draft / Internal |
2 | β Special / Reserved (Not public) |
Important:
This logic is inverted compared to many modern systems. In this KB, published articles usetype = '0'.
Newly created articles were saved with type = '1' or type = '2'
Public KB pages filter articles using:
As a result, those articles were correctly excluded from public display
This is not a database bug, not a PHP bug, and not a caching issue.
If type is not 0, the article will not appear publicly.
β Changes take effect immediately
β No service restart required
This count should now match the number of articles shown on the KB page.
After adding new KB articles via admin panel
After modifying editor or save logic
After importing articles from another system
During KB migrations or schema reuse
KB administrators
Content editors
IT support teams
Developers maintaining custom KB systems
Fix:
Set type = '0'
Fix:
Check admin save logic and default value assignment
Fix:
Document type column behavior or rename at code level
Avoid auto-publishing sensitive/internal articles
Ensure only authorized users can change article visibility
Audit changes to the type column
Maintain role-based access control in admin UI
Clearly document visibility logic (type meanings)
Add labels in admin UI (Published / Draft / Special)
Validate article state before saving
Periodically audit hidden articles
Avoid ambiguous column names in future schema designs
When KB articles appear in SQL but not on public pages, the issue is almost always due to visibility filtering rather than missing data. In this KB system, the type column controls publication state, with type = '0' representing published content.
Understanding and documenting this logic ensures:
Faster troubleshooting
Fewer publishing mistakes
Stable and predictable KB behavior
With the correct visibility flag applied, articles become publicly visible immediately and consistently.