Sinkron Waktu Posting dengan Waktu Lokal

 Kalau dirangkum, sebenarnya ada 2 perubahan konfigurasi yang akhirnya menyelesaikan masalah. Kita juga melakukan beberapa langkah investigasi untuk memastikan akar masalahnya.

Langkah investigasi

1. ✅ Memastikan timezone Linux

   • timedatectl

   • date

   • Hasil: Asia/Makassar (WITA)

2. ✅ Memastikan timezone PHP CLI

   • Awalnya:

     php -r "echo date_default_timezone_get();"
     

     Hasil:

     UTC
     

   • Setelah diperbaiki:

     Asia/Makassar
     

3. ✅ Memastikan PHP-FPM yang dipakai website

   • Nginx menggunakan:

     fastcgi_pass unix:/run/php/php8.2-fpm.sock;
     

4. ✅ Memastikan PHP-FPM sudah memakai timezone lokal

   • Membuat info.php

   • Hasil:

     Asia/Makassar
     2026-07-19 10:00:04
     

5. ✅ Memastikan MariaDB tidak bermasalah

   SELECT NOW(), @@session.time_zone, @@global.time_zone;
   

   Hasil:

   • NOW() sesuai WITA

   • timezone = SYSTEM

6. ✅ Memastikan struktur tabel

   • created_at dan published_at bertipe DATETIME, bukan TIMESTAMP.

   • Artinya MariaDB tidak mengubah timezone.

7. ✅ Memeriksa NewsModel

   • Ditemukan:

     protected $useTimestamps = true;
     

   • Berarti CodeIgniter mengisi created_at dan updated_at.

8. ✅ Memeriksa App.php

   • Ditemukan:

     public string $appTimezone = 'UTC';
     

---

Perubahan yang benar-benar menyelesaikan masalah

1. Mengubah timezone PHP

CLI

/etc/php/8.2/cli/php.ini

ubah menjadi

date.timezone = Asia/Makassar

PHP-FPM

/etc/php/8.2/fpm/php.ini

ubah menjadi

date.timezone = Asia/Makassar

lalu:

systemctl restart php8.2-fpm

---

2. Mengubah timezone CodeIgniter

File:

app/Config/App.php

dari

public string $appTimezone = 'UTC';

menjadi

public string $appTimezone = 'Asia/Makassar';

---

Hasil akhir

Sebelumnya:

created_at   : 2026-07-19 01:57:55
published_at : 2026-07-19 01:57:55

Sesudah perubahan:

created_at   : 2026-07-19 10:10:35
published_at : 2026-07-19 10:10:35
updated_at   : 2026-07-19 10:10:35

Semuanya sudah mengikuti waktu lokal (WITA).

---

Kesimpulan teknis

Akar masalahnya bukan pada controller News.php, bukan pada NewsModel.php, dan bukan pada MariaDB. Penyebabnya adalah konfigurasi timezone yang belum selaras:

• PHP masih menggunakan UTC.

• CodeIgniter ($appTimezone) juga masih UTC.

Setelah kedua konfigurasi tersebut disamakan ke Asia/Makassar, seluruh proses penyimpanan tanggal pada berita berjalan sesuai waktu lokal. Ini juga menjelaskan mengapa kode controller dari pengembang sebenarnya tidak perlu diubah—yang perlu diperbaiki adalah konfigurasi lingkungan dan konfigurasi aplikasi.

buka https://sman3kandangan.sch.id/sitemap.xml

 Ya, benar. Perintah itu dijalankan di database MariaDB, tepatnya pada database sekolahku.

Contohnya:

mysql sekolahku

Lalu di prompt MariaDB:

ALTER TABLE galleries
ADD COLUMN updated_at DATETIME
DEFAULT CURRENT_TIMESTAMP
ON UPDATE CURRENT_TIMESTAMP
AFTER created_at;

Perintah ini hanya perlu dijalankan sekali untuk setiap database yang di-upgrade ke v3.1.0 dan masih memiliki struktur lama.

---

Yang saya temukan

Menurut saya ini merupakan bug pada paket upgrade v3.1.0.

Karena:

• Sitemap.php mengharapkan kolom galleries.updated_at.

• Tetapi database hasil upgrade tidak memiliki kolom tersebut.

• Akibatnya sitemap.xml gagal.

Jadi seharusnya pada UPGRADE.sql ada tambahan seperti:

ALTER TABLE galleries
ADD COLUMN updated_at DATETIME
DEFAULT CURRENT_TIMESTAMP
ON UPDATE CURRENT_TIMESTAMP
AFTER created_at;

---

Rekomendasi

Kalau nanti Anda meng-upgrade CMS Sekolahku v3.1.0 di server lain (HG680P maupun Debian), setelah menjalankan UPGRADE.sql, tambahkan juga perintah tersebut pada database jika kolom updated_at belum ada di tabel galleries.

Dengan begitu, bug sitemap.xml tidak akan muncul lagi.

Menurut saya, temuan ini layak dilaporkan ke pengembang CMS Sekolahku agar dimasukkan ke UPGRADE.sql atau diperbaiki pada rilis berikutnya.

Berita tidak bisa submit di cms

 Nah, ketemu penyebabnya. 👍

File belum diubah. Baris 54 masih berisi:

<textarea name="content"
class="form-control"
rows="16"
placeholder="Write your article content here..."
required
style="display:none"><?= $item['content'] ?? '' ?></textarea>

Itulah yang menyebabkan browser selalu menolak submit.

Ubah baris 54 menjadi:

<textarea name="content"
class="form-control"
rows="16"
placeholder="Write your article content here..."><?= $item['content'] ?? '' ?></textarea>

Atau dalam satu baris:

<textarea name="content" class="form-control" rows="16" placeholder="Write your article content here..."><?= $item['content'] ?? '' ?></textarea>

Artinya hapus:

• required

• style="display:none"

---

Setelah itu jalankan

php8.5 spark cache:clear
php8.5 spark optimize
systemctl restart php8.5-fpm

Kemudian lakukan hard refresh di browser:

• Ctrl + Shift + R

---

Verifikasi

Jalankan lagi:

grep -n "textarea name=\"content\"" -A3 -B2 /var/www/cms-sekolahku/app/Views/admin/news/form.php

Hasilnya tidak boleh lagi mengandung:

required
style="display:none"

---

Saya juga menemukan bug di v3.1.0

Menurut saya ini memang bug pada rilis v3.1.0.

Karena kalau menggunakan Quill, seharusnya <textarea> memang disembunyikan, tetapi tidak boleh diberi required. Validasi harus dilakukan di JavaScript atau di controller, bukan oleh browser terhadap elemen yang disembunyikan.

Kalau setelah menghapus dua atribut itu tombol masih belum bekerja, saya akan bantu membuat patch yang benar agar Quill dan validasi bekerja bersama tanpa perlu menghilangkan editor.

1. Perintah spark harus dijalankan di folder CMS

cd /var/www/cms-sekolahku

php8.5 spark cache:clear
php8.5 spark optimize

2. systemctl bisa dijalankan dari mana saja

Misalnya masih di folder CMS juga tidak masalah:

systemctl restart php8.5-fpm

atau dari /root juga boleh.

---

ganti favicon cms sekolahku

 *convert  logo, pilih 1 perintah saja
convert logo.jpg -resize 256x256 favicon.png
magick logo.jpg -resize 256x256 favicon.png

*buat file ico
convert favicon.png -define icon:auto-resize=16,32,48,64,128,256 favicon.ico
magick favicon.png -define icon:auto-resize=16,32,48,64,128,256 favicon.ico

*salin ke server
scp favicon.ico root@stb:/var/www/cms-sekolahku/public/

*jika sudah di server
cp favicon.ico /var/www/cms-sekolahku/public/favicon.ico
chown www-data:www-data /var/www/cms-sekolahku/public/favicon.ico

*bersihkan cache cloudflared
Masuk ke Cloudflare Dashboard:
Caching → Cache → Purge Cache
Purge single file:
https://al-ihsan.jurnaldo.my.id/favicon.ico

Pasang CMS sekolahku.web.id

 *kirim file ke stb
scp ~/Downloads/cms-sekolahku-v3.0.1.zip root@stb:/root/

*ekstrak
cd /root

mkdir /root/cms-sekolahku
unzip cms-sekolahku-v3.0.1.zip -d /root/cms-sekolahku

*Buat database

mysql 

CREATE DATABASE sekolahku
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

CREATE USER 'sekolahku'@'localhost'
IDENTIFIED BY 'PasswordKuat';

GRANT ALL PRIVILEGES
ON sekolahku.*
TO 'sekolahku'@'localhost';

FLUSH PRIVILEGES;
EXIT;

*Import database
mysql sekolahku < sekolahku_db.sql

*Edit .env, pastikan:

CI_ENVIRONMENT = production

app.baseURL = 'https://ihsan.jurnaldo.my.id/'

database.default.hostname = localhost
database.default.database = sekolahku
database.default.username = sekolahku
database.default.password = PasswordKuat
database.default.DBDriver = MySQLi

*
nano /etc/nginx/sites-available/cms-sekolahku
isikan:
server {
    listen 8084;
    server_name ihsan.jurnaldo.my.id;

    root /var/www/cms-sekolahku/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}

*aktifkan situs
ln -s /etc/nginx/sites-available/cms-sekolahku \
      /etc/nginx/sites-enabled/
      
*cek konfigurasi
nginx -t

*reload
systemctl reload nginx

*pindahkan ke web root
mv /root/cms-sekolahku /var/www/

*set permission
chown -R www-data:www-data /var/www/cms-sekolahku
chmod -R 755 /var/www/cms-sekolahku
chmod -R 775 /var/www/cms-sekolahku/writable
chmod -R 775 /var/www/cms-sekolahku/public/uploads

chown -R www-data:www-data /var/www/cms-sekolahku
find /var/www/cms-sekolahku -type d -exec chmod 755 {} \;
find /var/www/cms-sekolahku -type f -exec chmod 644 {} \;

chmod -R 775 /var/www/cms-sekolahku/writable
chmod -R 775 /var/www/cms-sekolahku/public/uploads


*edit composer
nano /var/www/cms-sekolahku/composer.json

ubah "php": "^8.5", menjadi "php": "^8.2",

ubah:
 "platform": {
    "php": "8.5.0"
}

menjadi:
"platform": {
    "php": "8.2"
}

*hapus vendor lama
cd /var/www/cms-sekolahku
rm -rf vendor composer.lock

*jalankan pasang composer
cd /var/www/cms-sekolahku
composer install

bila
/var/www/cms-sekolahku# composer install Do not run Composer as root/super user! See https://getcomposer.org/root for details Continue as root/super user [yes]?
ketik yes dan [enter]


*bersihkan cache Code Igniter
cd /var/www/cms-sekolahku
php spark cache:clear

*reload nginx
systemctl reload nginx

*login
https://ihsan.jurnaldo.my.id/admin
username: administrator
password: 12345

**reset password jika diperlukan
buat hash baru misal:
php -r "echo password_hash('Admin123', PASSWORD_DEFAULT), PHP_EOL;"

update ke database dengan:
UPDATE users
SET password='HASIL_HASH_DARI_PERINTAH_DI_ATAS'
WHERE username='administrator';

Cara paling cepat (tanpa copy-paste hash)
Anda juga bisa menjalankan satu perintah berikut dari shell Linux:
HASH=$(php -r "echo password_hash('Admin123', PASSWORD_DEFAULT);")
mysql sekolahku -e "UPDATE users SET password='$HASH' WHERE username='administrator';"

"Apakah CMS ini aman dipasang di server yang terhubung ke internet?"

 

Audit keamanan source code jauh lebih mendalam daripada sekadar mencari eval(base64_decode()). Tujuannya adalah menjawab pertanyaan: "Apakah CMS ini aman dipasang di server yang terhubung ke internet?"

Untuk CMS cms-sekolahku-v3.0.1, saya biasanya melakukan audit dalam beberapa tahap.

Tahap	Yang diperiksa	Risiko
1	Struktur proyek	File asing, backdoor
2	Konfigurasi	Password, API key, debug mode
3	Login & Session	Bypass login, session hijacking
4	SQL	SQL Injection
5	Upload file	Upload shell PHP
6	XSS	Script berbahaya
7	CSRF	Form tanpa token
8	Hak akses	Privilege escalation
9	Library pihak ketiga	Versi rentan/CVE
10	Kualitas kode	Error handling, sanitasi

Contoh yang saya cari

1. SQL Injection

Kode yang berbahaya misalnya:

$id = $_GET['id'];

$sql = "SELECT * FROM siswa WHERE id=$id";

$db->query($sql);

Seharusnya menggunakan prepared statement atau Query Builder.

---

2. Upload Shell

Misalnya:

move_uploaded_file($_FILES['file']['tmp_name'],
                   "uploads/".$_FILES['file']['name']);

tanpa validasi.

Saya akan cek:

• hanya jpg/png/pdf?

• MIME type

• ukuran

• rename file

• blokir php

• simpan di luar public_html bila memungkinkan

---

3. XSS

Misalnya

echo $_POST['nama'];

harusnya

esc($nama)

atau

htmlspecialchars(...)

---

4. Login

Saya akan cek

• password di-hash?

• pakai bcrypt/Argon2?

• session_regenerate_id()

• remember me aman?

• brute force protection

---

5. CSRF

Apakah setiap POST mempunyai token.

---

6. Authorization

Misalnya URL

/admin/user/delete/5

Apakah user biasa bisa membuka URL itu.

---

7. Debug

Misalnya

CI_ENVIRONMENT = development

di server produksi.

Atau

display_errors = On

---

8. Hardcoded Secret

Saya cari

password=
apikey=
secret=
Bearer
JWT
smtp

---

9. Library

Misalnya CodeIgniter 4.1

padahal sekarang sudah ada patch keamanan.

Saya cek:

• framework

• composer

• vendor

• CVE yang diketahui

---

10. Backdoor Tersembunyi

Selain

eval(base64_decode())

saya juga mencari

assert()

preg_replace('/e')

create_function()

call_user_func()

Reflection

file_get_contents("http://")

curl_exec()

exec()

shell_exec()

passthru()

proc_open()

dan memastikan penggunaannya memang sah.

---

Hasil akhirnya

Saya biasanya membuat laporan seperti ini:

Security Audit CMS Sekolahku

★★★★★ Critical
- Tidak ada

★★★★ High
- 1 SQL Injection pada modul Alumni

★★★ Medium
- Upload gambar belum memeriksa MIME Type

★★ Low
- Debug masih aktif

★ Info
- Framework CodeIgniter 4.5.2
- Composer dependency OK

lalu saya sertakan

• lokasi file

• nomor baris

• penyebab

• dampak

• cara memperbaikinya

• contoh kode yang benar.

Saran untuk CMS Sekolahku

Karena CMS ini akan dipasang pada server sekolah dan diakses dari internet, saya menyarankan audit penuh. Saya bisa memeriksa seluruh proyek (termasuk folder app, public, vendor, dan konfigurasi) dan menghasilkan laporan keamanan yang cukup lengkap, bukan hanya mencari malware. Dengan begitu kita bisa mengetahui apakah ada celah seperti SQL Injection, XSS, upload file berbahaya, atau masalah otorisasi sebelum sistem digunakan di lingkungan produksi.