Ano ang PrizeX
Ang PrizeX ay platform ng premyo, gaming, at marketplace na nakabase sa PHP: auction, lottery, mystery box, isang kumpol ng arcade na laro, multi-vendor na e-commerce na shop, at ekonomiya ng wallet/coin — lahat sa iisang self-hosted na aplikasyon. Dumarating ito na may arkitekturang plugin/tema, admin panel, at 38 plugin ng payment gateway na sumasaklaw sa card, wallet, crypto, at mga panrehiyong processor, kasama ang 3 manual na paraan ng pagbabayad na inihasik mismo ng kernel.
Walang SaaS lock-in: ini-install mo ito sa sarili mong hosting, sa iyo ang database, at makakakuha ka ng lifetime updates sa lisensya. Bawat vertical (auction, lottery, mystery box, laro, shop) ay puwedeng buksan o isara nang hiwa-hiwalay mula sa admin panel — puwedeng tumakbo ang bagong install bilang produktong iisa lang ang vertical o bilang buong suite.
Hindi kailanman mahigpit na umaasa sa isang plugin ang pangunahing code. Ang bawat vertical, payment gateway, at social login ay isang plugin sa ilalim ng plugins/ na puwedeng i-activate, i-deactivate, o burahin nang hindi nasisira ang iba pang bahagi ng site.
Prefix ng table na tbl_, walang ORM, halos puro prepared statement. Pag-aari at pinamamahalaan ng bawat plugin ang sarili nitong mga table sa pamamagitan ng idempotent na installer na db_delta().
Saan ito tumatakbo
Tumatakbo ang PrizeX sa karaniwang shared hosting o sa VPS — walang espesyal na configuration ng server maliban sa web server na kayang mag-rewrite.
* May ilang file sa ilalim ng database/migrations/ na gumagamit ng extension na ADD COLUMN IF NOT EXISTS na para lang sa MariaDB. Tinatanggihan ito ng plain na MySQL 8.0/8.4 — gamitin ang MariaDB para sa database, sa development man o sa production.
Pagpapatakbo ng bagong install
Walang install wizard para sa bagong setup — direkta mong ini-import ang schema at kino-configure ang environment file.
- I-install ang mga PHP dependency:
composer install - Kopyahin ang template ng environment at punan ang iyong mga database credential:
cp .env.example .env - I-import ang
database/production.sqlsa database na nakapangalan sa iyong.env— dito nalilikha ang buong schema. - Palitan ang inihasik na admin account (tingnan ang paalala sa ibaba), pagkatapos ay mag-log in sa
/admin/.
tbl_admin row (admin@wowcodes.in) ang database/production.sql na pare-pareho ang password hash sa bawat install. Burahin ito at ipasok ang sarili mo bago maging live:
php -r "echo password_hash('your-password', PASSWORD_BCRYPT), \"\n\";"DELETE FROM tbl_admin;
INSERT INTO tbl_admin (username, email, password, image, status, permission_settings)
VALUES ('yourname', 'you@example.com', '<hash from the command above>', '', 1, 1);Para sa lokal na development, gumagana ang built-in na PHP server nang walang Apache: php -S localhost:8000 router.php — tandaan lang na buong-buo nitong binabalewala ang .htaccess, kaya manu-manong isinasagawang muli ng router.php ang parehong mga patakaran sa routing (tingnan ang Pag-setup ng web server).
Mga environment variable
Lahat ng setting na nakadepende sa environment ay nasa .env, na kinakarga sa pamamagitan ng vlucas/phpdotenv. Kopyahin ang .env.example bilang .env (hindi kasama sa git) at itakda ang totoong halaga kada environment — ang mga database credential, kahit man lang, bago i-import ang schema.
Ang mga setting para sa buong site na hindi nakadepende sa environment (pangalan ng app, currency, mga aktibong plugin, aktibong tema, at mga toggle kada vertical) ay nasa database, sa tbl_settings, at pinamamahalaan mula sa admin panel sa halip na sa mga file.
Pag-setup ng web server
Ang mga patakaran sa routing at seguridad — malilinis na URL, pagharang sa direktang access sa .env/connection.php/mga log, at pagpigil sa na-upload na content na maisagawa bilang PHP — ay nakatakda sa mga .htaccess file sa buong proyekto. Natively itong binabasa ng Apache at LiteSpeed/OpenLiteSpeed.
Sa nginx, gamitin ang nginx.conf.example, na sinasalamin ang bawat isa sa mga patakarang iyon bilang isang server{} block ng nginx — iakma ang server_name, root, at ang socket ng PHP-FPM sa iyong environment.
.htaccess (production), router.php (lokal na php -S dev server), at nginx.conf.example (nginx) ay bawat isa ay hiwalay na nagsasagawang muli ng parehong mga patakaran sa routing. Ang pagdaragdag ng bagong malinis na URL na route ay nangangahulugan ng pag-update sa tatlong ito.
Arkitektura ng request
Ang bawat pahina ng storefront (index.php, item.php, …) ay nagbo-boot sa pamamagitan ng includes/header.php, sa ganitong pagkakasunod-sunod:
Sinisimulan ng connection.php ang session, kumokonekta sa pamamagitan ng mysqli gamit ang mga credential sa .env, kinakarga ang tbl_settings sa mga constant gaya ng APP_NAME at CURRENCY, at nilo-log in ang kasalukuyang user kasama ang isang row ng device fingerprint. Bino-boot ng plugins_load() ang bawat aktibong plugin at pinapaputok ang plugins_loaded na hook — dito lamang nagiging kilala ang tunay at kasalukuyang hanay ng mga aktibong vertical, kaya pagkatapos nito ay muling sinusuri ng header.php ang mga lumang flag sa settings (shop, multivendor, auction, lottery) laban sa aktwal na estadong aktibo ng plugin.
Hindi dinodoble ng admin panel ang bootstrap na ito — nagtatakda ang admin/includes/connection.php ng configuration ng session/error na para lang sa admin at saka isinasama ang parehong includes/connection.php sa root.
Sistema ng plugin
Ang plugin ay plugins/<slug>/plugin.php — metadata sa header comment na binabasa nang hindi isinasagawa ang file — kasama ang opsyonal na plugin.json para sa mas mayamang impormasyon sa catalog. Iniimbak ang mga aktibong plugin bilang JSON array sa tbl_settings.active_plugins.
- Pagmamay-ari ng table — nagtatakda ang bawat plugin ng sarili nitong
includes/schema.php, na tinatawag kapag na-activate, gamit ang idempotent na helper nadb_delta()(CREATE TABLE IF NOT EXISTS+ALTER TABLE ADD COLUMNna pandagdag lamang). Hindi kailanman ginagalaw ng isang plugin ang mga table ng ibang plugin. - Nauunang kumarga ang mga registry — ang
add_admin_page,add_route,add_cron_job,add_api_route, atregister_moduleay nakatakda nang lahat bago kumarga ang kahit anong plugin, kaya hindi kailanman nagiging fatal ang mga top-level na tawag ng isang plugin kahit na hindi pala ito aktibo. - Malinis na pag-alis — ang pagbura sa isang plugin ay nagpapatakbo ng
uninstall.phpnito at nag-aalis ng folder nito; walang dapat sa labas ngplugins/<slug>/ang mahigpit na nag-re-require sa mga file nito, kaya patuloy na gumagana ang iba pang bahagi ng site kahit wala na ang plugin.
Sistema ng tema
Ang tema ay nasa assets/themes/<slug>/ — isang manifest.php, theme.css, functions.php para sa mga theme hook, at opsyonal na components/. Nakaimbak ang aktibong tema sa tbl_settings.active_theme, at editorial ang fallback kapag wala nang naitakda.
Ganito ang pagkakasunod-sunod ng paghahanap ng component: ang sariling components/ na folder ng aktibong tema, saka ang directory ng component na idineklara ng isang plugin sa pamamagitan ng register_module(), saka ang ibinabahaging components/ sa root. Sa praktika, nangangahulugan ito na minsan lang naroroon ang ibinabahaging default sa components/, at kahit anong tema — o aktibong vertical na plugin — ay puwedeng palitan ang isang tiyak na landas ng component gamit ang sarili nitong kopya.
Database
Prefix ng table na tbl_, raw na mysqli, halos puro prepared statement. Mga SQL file, ayon sa pagkakasunod-sunod ng awtoridad:
database/core-schema.sql— mga kernel table lamang na manu-manong inaalagaan; sadyang hindi kasama ang mga table ng vertical/plugin.database/production.sql— awtomatikong nabubuo (core schema + ang sariling install routine ng bawat plugin, na idinump mula sa isang scratch database). Ito ang ini-import mo para sa bagong install.database/sandbox.sql— demo/seed na dataset para sa lokal na development.database/migration.sql— pinagsama-sama at idempotent na upgrade script para sa mga umiiral nang install.database/migrations/<slug>/up.sql(+down.sqlkung nababaligtad) — isang file kada indibidwal na migration.
Mga modyul
Kasama sa iisang installation ang bawat modyul, at hiwa-hiwalay itong binubuksan mula sa admin panel.
Auction
Live na bidding na may multi-vendor na seller portal at commission engine. Pangunahing plugin: plugins/auction.
Lottery
Mga draw na may ticket at may nako-configure na iskedyul, premyo, at abiso sa panalo. Pangunahing plugin: plugins/lottery.
Mystery box
Nako-configure na prize pool na may reveal animation — bumibili ang user ng box at agad nitong nakikita ang napanalunan. Plugin: plugins/mystery-box.
Mga laro at reward
Isang arcade cluster sa ilalim ng games/ kasama ang mga plugin para sa engagement/kita:
Shop at marketplace
Isang multi-vendor na e-commerce layer na may mga kagamitan sa promo at merchandising. Mga pangunahing plugin: plugins/shop, plugins/multivendor.
Wallet, coin at pamumuhunan
Isang wallet na gumagana sa buong platform at ibinabahagi sa lahat ng modyul.
Referral at reward
Auth, tiwala at compliance
Mga utility
Admin panel
Nasa ilalim ng admin/ ang admin panel, at hindi nito dinodoble ang bootstrap ng storefront — nagtatakda ito ng configuration ng session/error na para lang sa admin, tapos isinasama ang parehong includes/connection.php sa root. Nagrerehistro ang mga pahina sa pamamagitan ng add_admin_page(), na siyang humahawak sa entry sa sidebar, sa paglilimita ayon sa kakayahan, sa CSRF, at sa balangkas ng auth; ang mga JSON action na para lang sa admin ay nagrerehistro sa pamamagitan ng add_admin_ajax() at dumadaan sa admin/ajax.php?action=<slug>.
Mga item, banner, pahina, menu, blog.
Pamamahala ng awtomatiko at manual na gateway, pagsusuri ng manual na bayad, pag-export ng payout.
Mga user group, role, detalye ng seller, impersonation.
Pag-export ng transaksyon/order/user, cron log, pagsubaybay sa error, log ng aktibidad ng admin.
Mga email campaign, template, newsletter, push notification, log ng notification.
I-activate/i-deactivate ang mga plugin at tema, mga setting ng SEO kada pahina, mga setting para sa buong site.
Mga tema ng storefront
Limang tema ang kasama sa ilalim ng assets/themes/, at mapapalitan ang mga ito kada install mula sa admin panel. Nagtatago ang bawat tema ng sarili nitong kopya ng mga ibinabahaging component sa sarili nitong components/ na folder.
Simple at modernong hitsura na may puting card at malalambot na anino — ligtas at maraming gamit na pagpipilian para halos sa kahit anong klase ng shop.
Malinis na hitsurang tila magasin na may maiinit na tono ng papel at malinaw na tipograpiya, para sa pinakintab at mapagkakatiwalaang storefront.
Default na fallback na temaMatapang at maluhong madilim na tema na may gintong accent — dinisenyo para maging kapana-panabik at high-end ang dating.
Mainit at masaganang palamuting hitsura na hango sa mga tradisyunal na palengke, may suporta sa mga wikang right-to-left.
Nakakakilabot at mapistang pana-panahong hitsura — malalalim na lilang backdrop na may nagniningning na kulay-kalabasang highlight.
Mga payment gateway
Pag-aari ng plugin ang 38 awtomatikong gateway — nasa sarili nitong plugins/gateway-<slug>/ na folder ang bawat isa at nirerehistro nito ang sarili sa kernel sa pamamagitan ng add_payment_gateway(). Gumagana agad ang pag-activate ng isa; walang anuman sa checkout dispatcher (payment_processor.php) ang nakakabit nang matigas sa isang partikular na gateway.
Ang 3 manual na paraan ay mga row na inihasik ng kernel na gateway_type = 'manual' at walang init/verify na code na iko-configure — nagpapakita lang ang mga ito ng instruksyon sa pagbabayad o ng QR code. Ang manual-gateway-builder na plugin ang nagbibigay-daan sa admin na magdagdag pa ng custom na manual na paraan ng pagbabayad nang hindi ginagalaw ang code.
May ilang gateway (Stripe, Razorpay, Midtrans, Venmo) na nagrerehistro rin ng render na hook para sa mga daloy ng checkout na nangangailangan ng JS sa panig ng kliyente — isang Stripe Checkout bootstrap, o isang Razorpay/Midtrans/Braintree SDK na kailangan munang ipagawa sa panig ng server ang order ID o token. Gumagana ang lahat ng ibang gateway nang wala nang anumang karagdagang pagkakabit sa kernel.
Mga layer ng API at AJAX
api/v1/— REST API na pinatutunayan ng JWT para sa mobile app at sa mga panlabas na consumer. Bineberipika ngapi/v1/middleware/*.phpangAuthorization: Bearer <token>na header. Nagdaragdag ang mga plugin ng sarili nilang endpoint sa pamamagitan ngadd_api_route().ajax/— panloob na AJAX na pinatutunayan ng session cookie para sa sariling JS ng storefront (cart, coupon, notification). Walang token layer — umaasa ito sa PHP session na inihahanda ngconnection.php.- Ang maluwag na
api/sa top level — mga sari-saring endpoint na walang bersyon gaya nggeo_location.php,exchange-rate.php, atofferwall_postback.php.
Mobile app
Ang mobile/ ay hiwalay na proyektong Capacitor + Ionic — isang WebView wrapper sa paligid ng live na site, hindi isang nakatayong SPA at hindi rin puro consumer lang ng api/v1. Itinuturo ng capacitor.config.ts nito ang server.url sa iyong domain. May sarili itong package.json at hindi ito bino-build mula sa root ng proyekto:
cd mobile
npm run sync
npm run open:ios
npm run open:androidPag-update at migration
Kumuha ng snapshot bago patakbuhin ang database/migration.sql o ang kahit aling database/migrations/<slug>/up.sql laban sa isang live na database:
mysqldump --single-transaction -u<user> -p<pass> <db> > pre-deploy-$(date +%Y%m%d-%H%M%S).sqlKaramihan sa mga migration ay may kasamang katugmang down.sql para baligtarin ang iisang pagbabagong iyon lang. Ang ilang nagbabago sa umiiral nang datos sa halip na magdagdag lang ng istruktura ay may kasamang down.sql na nagpapaliwanag kung bakit wala itong ginagawa — para sa mga iyon, ibalik mula sa dump na kinuha bago ang deploy kung kailangan mong mag-rollback.
Mga tala sa seguridad
- Palitan agad ang inihasik na mga admin credential pagkatapos ng import (tingnan ang Pag-install).
- Ang
.env,connection.php, at mga log file ay hinaharangan sa direktang HTTP access ng kasamang mga patakaran sa.htaccess/ nginx — huwag alisin ang mga patakarang iyon. - Ang na-upload na content ay inihahain sa paraang hindi ito maisasagawa bilang PHP, at ipinatutupad ito sa antas ng config ng web server, hindi sa antas ng aplikasyon.
- Ang mga credential ng payment gateway ay kino-configure kada gateway mula sa admin panel at iniimbak sa panig ng server — hindi kailanman inilalantad sa storefront.
Pagsubok
Walang PHPUnit suite. Pinapatakbo ng composer test ang bin/run-probes.php, na tinitipon ang bawat probe_*.php na file sa ilalim ng includes/_probes/ at ang sariling _probes/ na folder ng bawat plugin, pinapatakbo ang bawat isa bilang CLI subprocess at sinusuri ang exit code nito.
composer test # run every probe
php plugins/<slug>/_probes/probe_*.php # run a single probe directly
php bin/run-probes.php --all # also run destructive probes (skipped by default)Mga madalas itanong
Suporta at mga resource
May naiipit ka pa ba, o may kailangan kang hindi saklaw ng pahinang ito?