Error Handling
Relevant source files
The following files were used as context for generating this wiki page:Error handling within the oldwebsite project is implemented through a combination of server-side fallback mechanisms and client-side graceful degradation. The primary goal is to ensure a stable and consistent user experience by preventing application crashes or visible errors resulting from missing data or DOM elements. Instead of a centralized, complex error logging system, the application employs simple, localized checks.
The server-side logic, written in PHP, focuses on providing default content when specific translations are not available. On the client-side, JavaScript code defensively checks for the existence of HTML elements before attempting to manipulate them, which prevents runtime errors on pages that have different structures.
Server-Side Fallback Handling
Sources: iite/overview.php, inside/overview.php, departments/overview.php, apps/pages.php, apps/translations.json
Server-side error handling is centered around the internationalization (i18n) system. A helper function, t(), is used across multiple page-rendering PHP scripts to retrieve translated strings. This function includes a fallback mechanism to handle cases where a translation key is missing for the currently selected language.
Translation Fallback Mechanism
The t($key) function is responsible for fetching translated text. If a translation for a given $key and language ($lang) is not found in the translations array (loaded from apps/pages.php and apps/translations.json), it generates a human-readable default string by capitalizing the key and replacing underscores with spaces. This ensures that the UI never displays a raw key or an empty string, preventing layout breakage and providing a comprehensible, albeit untranslated, label.
The following diagram illustrates the logic of the t() function.
The implementation of this function is consistent across various PHP entry points:
function t($key) {
global $translations, $lang;
return isset($translations[$key][$lang])
? str_replace('\n', '<br>', $translations[$key][$lang])
: ucfirst(str_replace('_', ' ', $key));
}
Sources: iite/overview.php:16-20, inside/overview.php:16-20, departments/overview.php:16-20
For example, if the page title key iite_overview is requested for a language where it's not defined, the fallback mechanism would produce the string "Iite_overview" instead of causing an error.
Sources: apps/pages.php:10-15
Client-Side Graceful Degradation
Sources: apps/js/iite_components.js
The primary JavaScript file, iite_components.js, employs defensive programming by checking for the existence of DOM elements before binding event listeners or modifying their properties. This approach ensures that the script does not throw runtime errors on pages that may not contain all expected elements, allowing shared JavaScript to run across different page layouts without issue.
Element Existence Checks
Throughout iite_components.js, components are initialized only if their corresponding HTML elements are found on the page. This is typically done with a simple if (element) check or an early return if the element is null.
This table summarizes the key components and their existence checks.
| Component/Feature | Element ID/Selector | Check Logic | Purpose |
|---|---|---|---|
| Logo Color Changer | iitelogo | if (logo) | Prevents error if the logo element is not on the page. |
| Navbar Hiding | navbar, container-menu-nav | if (nav), if (containerMenuNav) | Hides navbar on specific pages; avoids error if navbar is absent. |
| Cookie Banner | cookies, btn-cookies | if (!cookiesBox) return;, if (btnCookies) | Ensures cookie logic only runs if the cookie banner UI exists. |
| Mobile Menu | menu-nav-mobile | if (!menu) return; | Skips mobile menu initialization if the button is not present. |
Sources: apps/js/iite_components.js:29-33, 43-48, 55, 69, 90
The sequence diagram below shows the process for initializing the cookie banner, highlighting the guard clause that prevents errors.
Sources: apps/js/iite_components.js:53-77
Disabled State UI Feedback
While not a traditional error handling mechanism, the application's CSS provides user feedback for disabled interactive elements. A disabled button receives a not-allowed cursor style, visually indicating to the user that the action cannot be performed. This prevents user confusion when an action is unavailable.
.scroll-btn:disabled {
opacity: 0.5;
cursor: not-allowed;
transform: none;
}
Sources: themes/css/iite.css:322-326
Summary
The error handling strategy in oldwebsite prioritizes application stability and a seamless user experience over complex error reporting. On the server, it gracefully handles missing translations by providing sensible defaults. On the client, it avoids script-breaking errors by defensively checking for the presence of DOM elements before interacting with them. This combined approach results in a robust front-end that can function correctly even with variations in page content and structure.