CodeCanyon School Management System - WordPress Plugin

Guide to Configuring and Using CodeCanyon School Management System in Practice

CodeCanyon School Management System is a large WordPress plugin for managing an educational institution, covering everything from classes, sections, and students to attendance, invoices, exams, study materials, notifications, and user dashboards. This guide does not repeat the short product description. Instead, it explains how to approach implementation thoughtfully: what to check before installation, which modules to enable first, how to structure roles, where errors usually appear, and how to tell when the system is actually ready for live use.

This guide is intended for a school site owner, a WordPress administrator, a developer, an educational center, or an agency helping a school move from spreadsheets and message threads to a single control panel. Inside, you will find a practical back-to-school launch scenario, recommendations for configuring permissions, payments, notifications, schedules, and results, plus a separate troubleshooting section for common issues.

This plugin belongs to the category of full-scale systems, so it should not be configured like a typical widget. The biggest implementation mistake is importing all students and opening portals right away without first checking sessions, roles, currency, notification templates, and test invoices. A better approach is to build a minimal working model with test data first, then move over the real records, and only after that give access to staff, parents, and students.

What Problem a School System Solves Inside WordPress

A school system inside WordPress has one major strength: it brings the institution's public website and its operational workflows into the same environment. If the site already includes school pages, news, admissions content, and contact information, the plugin adds a structured data layer on top of that: classes, sections, students, parents, teachers, invoices, attendance, study materials, and results. For a small educational center, this can be more convenient than using a separate external platform because content, forms, and user dashboards stay in one place.

At the same time, School Management System is not just a student registration form. Based on Weblizar sources and the current CodeCanyon page, the product includes an admin panel, separate roles, a multi-school structure, academic sessions, classes and sections, students, staff, attendance, homework, study materials, notifications, invoices, payments, exams, a library, transport, a hostel, certificates, live classes, and appearance settings. Some features depend on the product version, enabled modules, and additional integrations, so in a real project it is useful to keep your own list of enabled functionality.

The key practical takeaway is this: implementation should be planned around the school's workflow, not around the plugin menu. For example, if the institution only needs to manage student records and publish schedules, there is no reason to enable payment gateways, hostel features, the library, and every notification type on day one. If the site is meant to become a full parent portal, however, you need to think through roles, personal data, email templates, invoice visibility, payment verification, and support procedures in advance.

Common Use Cases Where the Plugin Is Especially Helpful

CodeCanyon School Management System makes sense when an educational organization needs a working portal, not just a brochure site. In practice, it is used for tasks like these:

• Managing the academic-year structure: sessions, classes, sections, subjects, and schedules.
• Creating student, parent, teacher, and staff records tied to specific roles.
• Tracking attendance and showing reports to students or parents in their dashboards.
• Preparing tuition invoices, recording payments, printing receipts, and reviewing payment history.
• Publishing study materials, homework, notifications, and announcements for specific groups.
• Organizing exams, admit cards, results, certificates, and academic reports.
• Splitting access between the administrator, school admin, teacher, accountant, librarian, student, and parent.

The "one site - one small school" scenario is usually the easiest. The "one WordPress installation - multiple schools or branches" scenario requires a stricter sequence: schools and sessions first, then administrators, then classes, sections, subjects, students, and staff. If you do it in reverse, some data will later need to be moved, reassigned, or deleted.

When the Product May Be More Than You Need

This plugin may be too heavy for a simple school landing page where a lead form and news section are enough. It is also not always a good fit for organizations that already use a government or corporate record system, require mandatory syncing with an external database, have strict legal requirements for personal data storage, or rely on a separate accounting platform. In those cases, a WordPress plugin may work only as a public-facing portal or an additional channel, not as the single source of truth.

Practical checkpoint: if the institution is not ready to assign someone to handle data ownership, backups, access permissions, and regular update testing, a full school plugin should be rolled out first with a limited feature set.

What to Check Before Installing on a Live Site

Before installing School Management System, it is important to protect the site from a common failure scenario: the plugin is technically activated, but real data is already being entered into an unprepared environment. Full school systems store many related entities. A mistake in the initial structure may not show up until later, when you need to generate a report, print an invoice, or give a parent access.

Start with a small technical and organizational audit. It takes less time than fixing incorrect roles and duplicate records after launch.

Technical WordPress Preparation

Make sure the site is up to date, runs on a supported PHP version, has current backups, and does not contain conflicting plugins that interfere with roles, user portals, admin caching, or form handling. The CodeCanyon page for the current Weblizar product lists compatibility across a broad range of WordPress versions, but you should not treat a single compatibility line as a guarantee. Real validation should always happen on a site copy.

• Create a full backup of files and the database before installation.
• Make sure the administrator has access to WordPress, hosting, and backup restoration tools.
• Disable aggressive caching for dashboard pages, payment forms, and dynamic panels.
• Test WordPress email delivery through an SMTP plugin or mail service if notifications are critical.
• Prepare test accounts for a student, parent, teacher, and accountant.

Organizational Data Preparation

A school system has a natural hierarchy. First come the session and school, then classes and sections, then subjects, staff, students, parents, invoices, and study materials. If you import students before setting up classes, you will create more manual work and a higher risk of inconsistent records. If you enable notifications before reviewing templates, users may receive confusing emails or SMS messages.

Prepare a spreadsheet or document with the minimum reference data:

• School or branch name, logo, contact details, address, and current academic session.
• A list of classes, sections, subjects, and responsible teachers.
• A list of staff roles: who tracks attendance, who enters grades, who manages invoices, and who handles library or transport tasks.
• Rules for student numbering, admission numbers, roll numbers, and invoice format.
• A set of email and message templates: new student, new invoice, payment confirmation, absence, homework, parent notification.

Security and Personal Data

A school system stores personal and academic data. Because of that, it should not be treated like a normal content plugin. Configure the minimum required permissions, do not assign the WordPress administrator role to staff without a clear reason, and check which pages are visible to logged-out users. If the project includes payments, reporting access, and personal dashboards, add a separate check for SSL, backups, and activity logging.

Do not import real data into a live site before testing roles. First verify that a student sees only their own materials, a parent sees only their child's data, a teacher sees assigned classes, and an accountant sees financial sections without unnecessary administrative access.

Installation and First Launch Without Putting Data at Risk

CodeCanyon School Management System is installed like a commercial WordPress plugin: the ZIP archive is uploaded through the plugins section, activated, and then its own school system menu appears in the admin panel. Details may vary by archive and version, so do not edit plugin files manually or copy an unverified archive over a working installation.

The point of the first launch is not to fill out every menu item. It is to confirm that the plugin has correctly created its tables, menu items, roles, and dashboard pages. After activation, open the new School Management section, review the main settings, and confirm that the modules described on the product page are present: Academic, Administration, Accounting, Examination, Students, Payment Gateway, SMS Template, Settings, and Shortcodes.

Basic Installation Sequence

1. Create a backup of the site and database.
2. Open the Plugins section in WordPress and upload the plugin ZIP archive through Add New.
3. Activate the plugin with Activate and wait for the school menu to appear.
4. Open the general settings and review the school name, current session, interface language, date format, currency, and mail settings.
5. Create a test school or test record if you are using multi-school mode.
6. Add one class, one section, one teacher, one student, and one parent.
7. Make sure the test roles can log in to their dashboards and see only the correct sections.

Do not enable every payment gateway and SMS provider immediately. First validate the basic navigation and core data records. After that, you can move on to notifications, invoices, and reports.

Initial Post-Activation Check

After installation, run a short smoke test. It confirms that the system is not broken at the routing, permissions, or interface level:

• The administrator opens the school system dashboard without PHP errors or blank screens.
• The created class appears in the class list and is available when adding a student.
• The section is linked to the class, and the subject is tied to the correct academic structure.
• The test student appears in the student list and is available in search.
• The student dashboard opens without showing cached content from another user.
• A test email or notification is sent to the test address if email templates are enabled.

If you hit access errors or blank pages at this stage, do not continue with import. First check the hosting error log, caching conflicts, user permissions, and whether all required pages or shortcodes are present.

Configuring Sessions, Classes, Sections, and the Academic Structure

For a school plugin, the academic structure is the foundation. Attendance, schedules, homework, invoices, exams, and reports all depend on it. The CodeCanyon page screenshots include dedicated screens for Sessions, Classes, Class Sections, Assign Sections, Subjects, and Timetable. That indicates the product expects a structured academic model to be configured in sequence, not a random list of students.

Sessions as the Boundaries of an Academic Period

A session is used to separate one academic period from another. If the school operates by school year, create a session for the current year. If the educational center works in cohorts, use whatever internal structure fits best, but do not mix different periods in the same structure unless there is a good reason. Later, the session affects student progression, invoice history, exam results, and reporting.

Do not delete an old session just because a new period has started. It is better to close it in your workflow and create a new one. Deleting historical data can break reports if student, payment, or exam records remain tied to that session.

Classes, Sections, and Subjects

Classes and sections should match the real schedule. If the school has "5A" and "5B," do not create two separate classes named "5A" and "5B" if the plugin supports classes and sections as separate entities. That approach makes grade-level reporting, student progression, and subject assignment easier. If the educational center does not use sections, create a minimal section such as "Main" so required fields are not left blank.

It is best to enter subjects after classes are configured. That way, the teacher, schedule, exams, and materials will all be linked to the correct level. If there are many subjects, use a consistent naming style: "Mathematics," "English," "History," rather than mixing abbreviations and full names.

Minimum Model for Testing

For the first validation pass, this structure is enough:

• One current academic session.
• One school or branch if multi-school mode is enabled.
• One class with two sections.
• Three subjects assigned to one teacher.
• One student and one parent linked to each other.

This model is small, but it lets you test nearly all key relationships: roles, the student record, attendance, schedule, study materials, notifications, and the dashboard.

Schedule and Calendar

The schedule in School Management System is useful only when class and subject data is already clean. Do not start with the calendar. First verify classes, sections, and subjects, then add lessons, exams, holidays, and events. Weblizar product updates mention calendar views for the admin panel and student dashboard, as well as holiday management, so the calendar can become a central point for students and staff. But its quality depends directly on having the reference data set up correctly.

Quick summary: if a class, section, or subject is named incorrectly, that mistake will repeat in the schedule, attendance, exams, invoices, and the dashboard. Fix your reference data before adding records at scale.

Multi-School Mode, Branches, and Student Transfers

The current Weblizar CodeCanyon page specifically highlights multi-school management, school admin assignment, transfer student, and transferred student history. That is an important difference compared to simpler school plugins. If the organization has one site and several branches, the plugin can become a shared management hub. But multi-school mode adds another layer of responsibility: each school's data must stay separated, and staff should not accidentally see other schools' classes, invoices, or students.

Do not enable the multi-school model just because it is in the menu. For a single school, it often makes setup more complicated. For a branch network, it is useful when each branch has its own administrators, classes, sessions, staff, and reporting. Before launch, decide what exactly counts as a separate school: a legal entity, a physical branch, a teaching location, an online division, or a program. That decision will later affect classes, transfer student workflows, financial reports, and access permissions.

How to Design Branches Without Chaos

In a multi-school setup, it is better to work from the top down. First create the list of schools or branches, then assign a school admin to each one, and only after that add classes, sections, staff, and students. If you start with students and only later decide which branch they belong to, the system quickly turns into a set of manual exceptions.

In practice, it is helpful to prepare a mapping table before working in WordPress:

• A short school or branch name to use in the admin panel.
• The formal name for documents, invoices, ID cards, and certificates.
• The responsible administrator and a backup staff member.
• Its own classes, sections, teachers, and financial rules.
• The public site pages where forms or dashboards for that specific school may appear.

If branches share teachers, do not assign overly broad permissions. It is better to review how the product handles staff, teacher assignments, and school-specific visibility. One teacher may work with several classes, but that does not mean they need full access to every branch.

Student Transfer as a Separate Process

Student transfer looks like a simple feature, but in practice it touches the student's history. During a transfer, it is important not to lose old records: attendance, invoices, results, documents, and comments. The CodeCanyon screenshots include a transfer student screen where you choose the class, section, and new school. That suggests transfers should be handled as a dedicated action, not by deleting one record and creating a new one.

Before transferring a student, run this short check:

1. The student is linked to the current session, class, and section.
2. All open invoices are clearly accounted for: paid, canceled, or reassigned according to internal policy.
3. The parent dashboard will not lose access to the necessary history.
4. The new school, class, and section have already been created.
5. After the transfer, the student appears in the new structure and the history is still available in reports.

If the organization transfers students between branches frequently, create a written internal process. Specify who initiates the transfer, who confirms the financial side, who checks the documents, and who informs the parent. The plugin helps execute the technical action, but it does not replace the school's internal policy.

Data Import, Bulk Operations, and Clean Reference Data

Bulk import almost always seems like the fastest way to launch. In reality, it is the riskiest stage. The WPSchoolPress alternative documentation explicitly notes that bulk import/export may depend on the add-on and CSV format, and the School Management System CodeCanyon page shows modules such as students list, admissions, roles, fee invoices, and attendance. That means the data is interconnected, and an error in one column can surface across multiple sections.

If your version of School Management System supports import, use it only after testing on a small sample. If import is unavailable or requires an additional module, do not try to work around that by writing directly to the database. School systems usually rely on many internal tables, relationships, and system fields. Direct database edits can easily create records that appear in one section and break in another.

What to Prepare Before Import

First, normalize the source spreadsheet. Remove duplicates, trailing spaces, inconsistent date formats, and accidental abbreviations. If the same class is recorded as "5," "Grade 5," "Class 5," and "V," the import will create disorder that later breaks filters and reports. A consistent vocabulary matters more than upload speed.

• Check required fields: name, admission number, class, section, parent relation, email, or phone number if those are used for login and notifications.
• Standardize the format for date of birth, admission date, and current session.
• Separate student, parent, and staff data if the import expects different files.
• Do not import real financial data until fee types and currency have been verified.
• Run a test with 5 to 10 rows and delete test records only through the built-in workflow.

How to Verify an Import After Upload

After a test import, do not stop at the student list. Open the student record, parent record, class, attendance, invoice, dashboard, and search. If data appears in only one table, that does not mean it is linked correctly. Check whether you can assign an invoice to that student, mark attendance, show a result, and open the dashboard.

Check email and phone separately. If notifications are enabled, an incorrect address or phone number will cause communication problems with parents. If the project uses SMS templates, decide in advance whether international numbers, spaces, a leading plus sign, local formats, and empty values are allowed.

Rolling Back Bulk Actions

Create a restore point before every import. Bulk deletion through the interface may be unavailable or may leave related items behind: invoices, attendance, exam results, materials, and user accounts. If a test import goes wrong, restoring a staging backup is often more reliable than manually cleaning up dozens of related records.

Import rule: one test file, one clear result, one restore point. Do not combine students, parents, staff, invoices, and results into one large import run without intermediate verification.

Reports, Analytics, and Management Decisions

The product page mentions dashboards, charts, academic reports, payments vs expense chart, attendance reports, financial reports, and student-wise invoice reports. These sections help school leadership see the overall picture, but their quality depends on disciplined data entry. A report does not fix chaos in the source records. It only displays that chaos more clearly.

Start by defining which management questions the system should answer. For example: how many students were absent by class, which invoices are overdue, which subjects show weak performance, which materials have been published, which payments have gone through, and which inquiries still need a response. If a report is not tied to a specific decision, staff will stop opening it very quickly.

Attendance Reports

Attendance is useful as more than just a log. It reveals risk groups, scheduling problems, and whether notifications are working. If a parent receives an absence message and the administrator can see weekly trends, the school can respond faster. But that only works if teachers mark attendance at the same time and according to the same rules.

Test the report on a sample class: mark one student as present, another as absent, and a third as late if that status exists in your version. Then open the report as an administrator and as a parent. If the status is unclear or appears under the wrong date, fix the date, session, or time zone settings before live rollout.

Financial Reports

Financial reports depend on fee types, invoices, concessions, payment methods, and statuses. If the school uses discounts or concession types, start by testing one simple flow: a standard invoice, a discount, a partial payment, a full payment, and an overdue balance. Only after that should you enable more complex rules. Do not mix internal accounting adjustments with the parent-facing interface unless you are sure how the plugin displays that data.

Academic Reports and Results

An academic report is valuable when the school has already aligned its grading scale, subjects, exam groups, and remarks. If every teacher enters comments differently, the report will look inconsistent. Agree on a structure for comments: a short observation, a recommendation, and the next step. Then check how those remarks are shown to the student and parent.

For dashboards and charts, do not chase the maximum number of widgets. It is better to keep a smaller set of indicators that actually support decisions: attendance, unpaid invoices, upcoming exams, new inquiries, recent materials, and critical notifications. A dashboard like that is less overwhelming for staff and more likely to become part of daily work.

Roles, Permissions, and User Dashboards: How to Avoid Opening Too Much Access

One of the strongest parts of the product is role-based access. The product page and Weblizar site list roles such as Super Admin, Admin, Teacher, Accountant, Receptionist, Student, Parent, Librarian, Transport, Exam Controller, Online Classes, and IT Support. In WordPress, this matters even more because the default site administrator role grants far too much access. A school system needs narrower roles: a teacher should handle academic actions, an accountant should manage invoices and payments, a parent should see their child's data, and a student should access available materials and results.

The product update history includes an important note about replacing the global WordPress capability manage_options with more specific permissions such as manage_classes and manage_admins for AJAX handlers. That is a good sign: the developer has paid attention to granular permission checks. Even so, the site administrator should still verify the actual section visibility in the installed version.

How to Assign Roles in Practice

Use the principle of least privilege. Start by creating test users and walking through the full flow as each one. Do not grant broad permissions to every staff member just for convenience. In a school system, that quickly becomes a risk: a teacher may see financial data, an accountant may see academic remarks, and a temporary staff member may gain access to personal records.

Testing Dashboards After Configuring Permissions

The check should not be formal. It should be scenario-based. Log in as a student and open the schedule, materials, invoice, and result. Then log in as a parent and verify that the linked student is the one being shown. Then log in as a teacher and confirm that the assigned class is available, but financial sections for other roles are not. Only after that should you invite real users.

A Common Caching Trap

If dashboard pages are cached like normal site pages, one user may see an old interface fragment or data from a previous state. For a school system, that is unacceptable. Exclude dashboard pages, login pages, payment pages, and dynamic shortcodes from caching. If a CDN or server-side cache is in use, check exclusions not only in the caching plugin but also at the hosting level.

Finances, Invoices, Payments, and Parent Notifications

The financial modules in School Management System require their own implementation sequence. The product page lists fee invoices, payment history, payment receipts, payment gateways, and integrations with multiple payment providers. That is convenient, but it also increases responsibility: a mistake in currency, statuses, email templates, or gateway test mode can create the wrong expectations for both parents and the accounting team.

Start without a live payment gateway. Create a test fee type, a test invoice, and one offline payment. Check how the invoice appears to the student and parent, how the status changes after payment, what the receipt looks like, and which notifications are sent. After that, you can connect online payments if they are required.

Invoice Configuration Sequence

1. Verify the currency, amount format, school details, and receipt text.
2. Create payment categories such as tuition, transport, study materials, or other categories the school actually uses.
3. Create a test invoice for one student and review it in the admin panel.
4. Open the parent or student dashboard and confirm that the amount, due date, and status are clear.
5. Run a test payment with an offline method or the gateway's test mode if it is available.
6. Review the payment history, receipt, and notification template.

When to Connect Payment Gateways

Payment gateways should be enabled only after the school has aligned its internal financial workflow. The product page lists several options: PayPal, Stripe, Razorpay, PayTM, Paystack, Pesapal, SSLCommerz, bank transfer, UPI, and others. There is no reason to enable everything. Choose one or two methods that parents actually need, that are supported in your country, and that the accounting team understands.

During testing, do not use real cards and do not send parents a payment link before verifying statuses. First create a small test invoice, then check a successful payment, a failed payment, a cancellation, a return login to the dashboard, and receipt printing. After each test, compare the data in the plugin with the data at the payment provider.

Email and SMS Templates

Notifications are not just a technical option. They shape trust in the system. The product claims to include email/SMS templates for student admission, invoice generated, online/offline fee submission, absent notification, homework notification, and other events. Before launch, edit the text, remove test wording, verify the variables, and send test messages.

Result check: the parent should receive a short, clear message explaining what happened, which student the event belongs to, where to view details, and whom to contact if something is wrong. If the message needs to be decoded by an administrator, the template should be rewritten.

Attendance, Schedules, Homework, and Study Materials

The academic modules provide most of the day-to-day value. While the financial side may be used periodically, attendance, schedules, materials, and homework can be used every school day. That is why they should be configured not as "extra features" but as the teacher's working process.

The product page and visuals show separate screens for View Attendance, Take Attendance, Timetable, Study Materials, Notices, Homework, and the student dashboard. That means the product is designed around the flow of "staff admin panel - student dashboard." If a teacher adds a material, the student should be able to find it without calling the office. If an absence is marked, the parent should see the correct status.

Attendance

Before daily use begins, verify three things: the student list in the class, the selected date, and the teacher's permissions. Attendance issues often happen not because the module is broken, but because the student is linked to the wrong class, section, or session. If a student does not appear in the attendance list, check the enrollment and class/section first instead of reinstalling the plugin.

A useful practice is to introduce one consistent rule. For example, the teacher marks attendance within the first ten minutes of class, the administrator reviews absences, and the parent notification is sent only after confirmation. If automatic messages are enabled without review, parents may receive false alerts because of a late arrival or an incorrect date selection.

Schedules and Events

The schedule should be easy for a student to read. Do not overload it with internal administrative notes. If the plugin includes fields for remarks or extra descriptions, use them for the teacher and administrator, but do not turn the public-facing view into a technical table. Review the schedule at a normal mobile-friendly width, because parents often open dashboards from a phone.

Materials and Homework

Study materials and homework are useful only when the school follows a clear naming system. Do not upload a file called "document.pdf" or "lesson1." A better structure is class, subject, topic, date, or lesson number. If the plugin accepts PDF, PNG, JPG, and video/YouTube materials in its eLearning module, decide in advance which formats are allowed. That reduces clutter in the student dashboard.

Safe Sequence for Publishing a Material

1. Select the class, section, and subject.
2. Add a short title the student will recognize without explanation.
3. Upload the file or provide a video link if that feature is available in your version.
4. Open the test student's dashboard and verify that the material is visible.
5. Check whether a notification was sent if it is enabled for this event.

After validation, you can repeat the same process for a real class. If a material does not appear, the most common causes are the wrong class/section, insufficient student permissions, a disabled module, a cached dashboard page, or an unsupported file type.

Exams, Results, ID Cards, and Certificates

The exam module is one of the most sensitive parts of the system. The product advertises exam management, admit cards, exam results, bulk print results, academic reports, certificates, and student ID cards. These features can be very useful, but they require careful template setup and output validation. An error in a name, class, exam schedule, or grade can quickly turn into a reputational problem.

Exams and Exam Schedules

Create exams only after classes, sections, subjects, and teachers have already been configured. Use clear exam names, dates, subjects, rooms, and centers if those are part of your school's process. If the product allows exam papers, room number, and exam center, do not leave those fields random. Students and parents will treat them as official information.

Admit Cards and ID Cards

An admit card and ID card are not just nice-looking documents. They pull data from the student, school, class, and exam. Before doing a bulk print run, generate one test card and review:

• The student name and number are correct.
• The school logo and school name are correct.
• The class, section, session, and exam are correct.
• The photo is correct if one is used.
• The QR code or extra fields are correct if they are enabled.

If the template prints poorly, do not edit the plugin files. First review the card background settings, logo dimensions, and available interface options. If exact control is not available, log the task for a developer or use a safe CSS adjustment in a child theme only for external display, not for the document generation logic.

Results and Academic Reports

Exam results should be entered according to a grading scale agreed on in advance. If the school uses grades, percentages, remarks, or grouped reports, first create one test exam result and check how it appears to the student and parent. The product changelog includes changes related to remarks and exam result settings, so some fields may be optional in your version.

Pre-publication check: open the result as an administrator, teacher, student, and parent. If even one role sees extra data or does not see a required field, do not publish results in bulk.

Practical Scenario: Launching a School Year in a Test School

Below is a working scenario that helps you validate CodeCanyon School Management System before moving real data. It can be run on a site copy or in a private test environment. The goal is to walk through the full path from school structure to the student and parent dashboards without touching real records.

Scenario Goal

Build a minimally working model of the school year: school, session, class, section, student, parent, teacher, schedule, attendance, one material, one invoice, and one result. After that, the administrator can see which modules are ready and where additional work is still needed.

Preparation

• The School Management System plugin is installed and activated.
• A site backup has been created.
• Test email addresses have been prepared for the student, parent, and teacher.
• Caching is disabled or proper exclusions are configured for dashboards.
• WordPress email delivery has been tested with a sample email.

Steps

1. Create the current academic session and mark it as active.
2. Add a school or use the main school if multi-school mode is not needed.
3. Create class "5" and section "A."
4. Add the subject "Mathematics" and assign a test teacher.
5. Create the student record and link it to the class, section, and current session.
6. Add a parent and verify the connection to the student.
7. Create one scheduled lesson and one test study material.
8. Mark attendance for the current school day.
9. Create a test fee invoice with a small amount and record an offline payment.
10. Create a sample exam, enter a result, and open it from the student dashboard.

Result Check

After running the scenario, verify four roles. The administrator should see the full chain of records. The teacher should see the assigned class, material, attendance, and academic actions. The student should see the schedule, material, invoice, attendance, and result. The parent should see the linked student's data, financial information, and academic events.

If any element does not appear, do not move on to bulk import. Check where the chain is broken: session, class, section, role, user account, shortcode, cache, or a disabled module.

A Detail That Often Gets in the Way

In full school plugins, the WordPress user account and the student record are not always the same object. A student may have a separate record in the school system and a linked WordPress user for login. If the dashboard opens but no data is shown, check not only the user role but also the link between the school record and the account.

Shortcodes, Widgets, and Displaying Information on the Site

School Management System does not work only inside the admin panel. On the CodeCanyon page, the screenshots include School Management Shortcodes and School Settings - School Shortcodes, and the description mentions an inquiry form via shortcode and a noticeboard widget. That means some features can be displayed on public or protected pages of the site. This is exactly where permissions and caching become especially important.

A shortcode is a convenient way to insert a form, dashboard, list, or widget into a WordPress page. But a shortcode should never become a shortcut around access control. If a page contains a student dashboard, an inquiry form, or financial information, it must be protected by the plugin's logic and excluded from cache.

Where to Use Shortcodes

• A student login or dashboard page.
• A parent dashboard page if the plugin separates roles.
• An enquiry form for admissions.
• A noticeboard or school announcement block.
• A results, admit card, or schedule page if supported by the settings.

Before publishing, open the page in incognito mode. A logged-out user should not be able to see personal data. Then log in as a test student and parent. Verify that the shortcode shows the correct content for each role.

A Safe CSS Tweak for a Dashboard Page

If you need to slightly improve the look of a dashboard or noticeboard page so it fits the site's theme, you can use a small CSS tweak through Appearance - Customize - Additional CSS or in a child theme. The example below does not change the plugin logic and does not touch School Management System files. Apply it only after checking the classes in the browser: if your version uses different CSS classes, replace the selectors with the actual ones.

/* More cleanly highlight the school dashboard container on a site page.
   Add this in Additional CSS or the child theme's style.css. */
.school-management-wrapper,
.wlsm-container {
  max-width: 1180px;
  margin: 0 auto;
}

.school-management-wrapper .notice,
.wlsm-container .notice {
  border-radius: 6px;
  line-height: 1.45;
}

Check the student dashboard page, the parent dashboard page, and the public form. If the blocks become too narrow, elements start overlapping, or system messages disappear, remove the CSS and go back to the original layout. Do not use CSS to hide errors, access warnings, or financial statuses.

Performance, Backups, and Ongoing Maintenance

A full school plugin creates more records and relationships than a typical content module. Invoices, attendance, materials, results, notifications, logs, and reports gradually increase database load. The Weblizar update history on CodeCanyon mentions optimization of AJAX loading, reductions in unnecessary DB queries, and caching improvements. That is useful, but it does not remove the need for ongoing maintenance on the site side.

What to Monitor Regularly

• Database size and backup frequency.
• PHP and JavaScript errors after WordPress, theme, and plugin updates.
• The load speed of dashboards and reports.
• The notification queue if SMTP or an external service is used.
• Correct cache exclusions for dynamic pages.
• User roles after updates and data imports.

For critical projects, it is worth having a staging copy. There you can test updates to School Management System, WordPress, the theme, caching, and payment integrations. Be especially careful with updates before exams, mass invoice sends, or the start of a new academic period.

Backup Restoration as Part of Implementation

A backup is useful only if you know how to restore it. Before moving real data, run one restoration test on a copy. Make sure the school tables, dashboards, users, and shortcode pages still open after restoration. If the database comes back but uploaded study materials are missing, the backup process needs to be fixed.

Maintenance rule: create a restore point before bulk import, plugin updates, role changes, and payment setup. That is faster than manually repairing related records later.

Common School Management System Issues and How to Diagnose Them

Troubleshooting works best when you follow symptoms rather than guesses. Below are issues typical of WordPress school systems: roles, caching, shortcodes, related records, notifications, and payment statuses. Some similar symptoms show up in changelogs and support/review materials for alternative school plugins, while others follow directly from the architecture of a full plugin.

The User Logs In to the Dashboard but Cannot See Their Data

Symptom: the student or parent logs in, the dashboard page opens, but the schedule, invoices, or results are empty.

Possible cause: the WordPress user exists, but it is not linked to the student or parent record inside the school system. The session, class, section, or role may also be incorrect.

What to check: open the student record and verify the current session, class/section, parent relation, and user account. Then log in with the test user after clearing the cache.

How to fix it: restore the link between the record and the user, assign the correct role, confirm the active session, and save the record. If the issue appeared after import, check the CSV format and required fields.

The Shortcode Shows a Blank Page or Someone Else's Content

Symptom: the dashboard or form page opens, but data does not load, or different users see the same fragment.

Possible cause: the page is cached, the shortcode was inserted on the wrong page, or the user does not have the required role.

What to check: cache exclusions, incognito mode, the login page, role permissions, and the correct shortcode from the plugin settings.

How to fix it: exclude dynamic pages from caching, verify the shortcode against the documentation or the School Shortcodes screen, and then repeat the test under different roles. If disabling caching solves the issue, configure targeted exclusions instead of turning off site caching entirely.

Emails or SMS Messages Are Not Being Sent

Symptom: an invoice is created, attendance is marked, or homework is added, but the user does not receive a notification.

Possible cause: WordPress is not sending mail, SMTP is not configured, the template is disabled, the event is not linked to a notification, or the SMS provider is not connected or funded.

What to check: a WordPress test email, email carrier settings, email/SMS templates, the sending log, SMS gateway settings, and the user's phone number.

How to fix it: first make sure a standard email can be sent successfully, then test the event template. Enable SMS only after email is working and the provider has been verified. If the message is delivered but the wording is unclear, fix the template before rolling it out to real parents.

The Teacher Cannot See the Class or Mark Attendance

Symptom: the teacher logs in to the panel, but the class list is empty or the action button is unavailable.

Possible cause: the teacher is not assigned to the subject, class, or section, or the role does not have the required permission.

What to check: the staff/teacher record, assigned subjects, class/section, current session, and role permissions.

How to fix it: assign the teacher to the correct academic structure, save the role, and log in again. If permissions disappeared after an update, compare the settings with a test copy and do not use the global administrator role as a quick workaround.

An Invoice Is Paid but the Status Did Not Update

Symptom: the parent made a payment, but the invoice still appears unpaid in the dashboard, or the payment history does not match the provider's data.

Possible cause: a callback/webhook error, gateway test mode, incorrect currency, a disabled payment method, a caching conflict, or an incomplete manual payment flow.

What to check: the payment gateway log, transaction status at the provider, payment method settings, currency, the success/cancel page, and the payment history inside the plugin.

How to fix it: repeat the test with a small invoice, verify the provider callback settings, and do not change the status manually without accounting reconciliation. If the error keeps happening, temporarily disable the online method and use offline tracking until the issue is resolved.

The Interface Changed or Elements Disappeared After an Update

Symptom: after updating the plugin, theme, or WordPress, some buttons, tabs, or tables display incorrectly.

Possible cause: a CSS/JavaScript conflict, stale cache, theme incompatibility, or a UI change in the new version. The product changelog includes fixes related to UI, AJAX, and styling, so changes like this should be tested in advance.

What to check: the browser console, cache conflicts, the staging copy, the active theme, recent updates, and user permissions.

How to fix it: clear the cache, test with a default theme, disable the conflicting plugin on a test copy, and only then apply a targeted CSS tweak. If the issue affects data or payments, roll back the update from backup and refer to the developer's documentation.

When CodeCanyon School Management System Is a Good Fit

This plugin is worth considering if you need a tight connection between a WordPress website and a school operations panel. It is especially relevant for a private school, educational center, branch-based educational organization, or agency building a site with dashboards, schedules, invoices, materials, and notifications. At the same time, the product requires disciplined implementation: a test environment, roles, reference data, backups, dashboard checks, and a careful staged rollout.

If you are ready to follow the validation process in this guide, the next step is a practical test and then download the CodeCanyon School Management System archive for a local or staging installation. Do not start with bulk import. Start with one class, one student, one parent, one invoice, and one result. If that chain works cleanly, scaling up will be much calmer.

If the school only needs a public website without dashboards, complex roles, and record management, this plugin may be too much. In that case, it is better to stick to an inquiry form, a news section, and a separate external service for internal processes. A good solution is not the one with the most modules, but the one the staff can maintain every day without creating data chaos.