Here I am, getting what I paid for…
whats is the matter to do upgrade ?
FYI
issu has gone after upgrade!
sh <(curl https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/preUpgrade.sh || wget -O - https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/preUpgrade.sh)
ouch… new commit… brb upgrading
Hello.
Go to the following location:
/usr/local/CyberCP/public
Check if you have this, if you do delete the file:
index.php
The full location should be “/usr/local/CyberCP/public/index.php”
Looks like it was an error on either the phpmyadmin.zip or the extraction code, as the vps i updated yesterday had the same issue as everyone else, but the one i just updated doesnt.
So it was fixed, but on my case the index.php was still there affecting it.
1 Like
correct
and the update script already do this… (if im not wrong , i see that at github)
you can use https://domain.tld:8090/logout
that will call “other” login page.
What i mean was that who still has that issue, can delete that index.php file at that location, and then no need to add “logout” anymore, as it will be fixed 
How your “/usr/local/CyberCP/public” should be:
How it became yesterday:
Delete the extra files. Only who updated at the wrong time yesterday was affected it seems.
1 Like
but not all understand about that…
thats why i still hoping developer do “automatic” fix for that
There, its just copy-paste + enter at putty:
rm -rf /usr/local/CyberCP/public/doc
rm -rf /usr/local/CyberCP/public/examples
rm -rf /usr/local/CyberCP/public/js
rm -rf /usr/local/CyberCP/public/libraries
rm -rf /usr/local/CyberCP/public/locale
rm -rf /usr/local/CyberCP/public/setup
rm -rf /usr/local/CyberCP/public/sql
rm -rf /usr/local/CyberCP/public/templates
rm -rf /usr/local/CyberCP/public/themes
rm -rf /usr/local/CyberCP/public/vendor
rm -f /usr/local/CyberCP/public/babel.config.json
rm -f /usr/local/CyberCP/public/ChangeLog
rm -f /usr/local/CyberCP/public/composer.json
rm -f /usr/local/CyberCP/public/composer.lock
rm -f /usr/local/CyberCP/public/config.sample.inc.php
rm -f /usr/local/CyberCP/public/CONTRIBUTING.md
rm -f /usr/local/CyberCP/public/favicon.ico
rm -f /usr/local/CyberCP/public/index.php
rm -f /usr/local/CyberCP/public/LICENSE
rm -f /usr/local/CyberCP/public/package.json
rm -f /usr/local/CyberCP/public/print.css
rm -f /usr/local/CyberCP/public/README
rm -f /usr/local/CyberCP/public/RELEASE-DATE-5.1.3
rm -f /usr/local/CyberCP/public/robots.txt
rm -f /usr/local/CyberCP/public/show_config_errors.php
rm -f /usr/local/CyberCP/public/url.php
rm -f /usr/local/CyberCP/public/yarn.lock
If you need help send me message with your AnyDesk
3 Likes
actually my production server already fixed from yesterday…
i just trying to make the solution for other cyberpanel user that not understand cli
1 Like
yeah… i just ask my provider… they provide hourly snapshot now (they forgot to put visibility option for that 
)
I’m on 2.3 commit 73d7ab44cfb1280d89ed848151813d06d40f97f9 and I still have to use the /logout hack to get access to Cyberpanel.
@usmannasir, I guess you’re already aware of this?
im so aware about that
thats why i stop use cyberpanel now
because the dev more focuss on “premium addon” or i can say… “requested addon” by some one here 
rather than fix the bug
Well… You had to use cli to install cyberpanel, so its just copy -pasting those comands…
If you are going to self-host your website but you can’t run commands yourself, perhaps you shouldn’t selfhost at all.
In that case would be best to get a shared / managed hosting, to have someone to fix it for you.
One command to fix the phpmyadmin issue:
sh <(curl https://raw.githubusercontent.com/tbaldur/cyberpanel-fix-23-06-2022/main/fix.sh || wget -O - https://raw.githubusercontent.com/tbaldur/cyberpanel-fix-23-06-2022/main/fix.sh)
1 Like
you made it… bravo bro
Hopefully this will help others…
2.3.3-dev
^^ version to type in when upgrade asks for version entry
It’s nice to finally have a working interface 
I experienced the same phpmyadmin problem as everyone on this thread, but none of the fixes worked for me. Someone did provide me a hint though… when mentioning v2.3.3. I couldn’t install a 2.3.3, but I could install 2.3.3-dev.
I learned about the dev builds a few years ago, using them for about 6 months. I went through months of trial & error woahs, while dealing with CentOS8/AlmaLinux8/CL8 fails before I finally had a working & stable instance of CyberPanel.
Honestly, I’ve just constantly been disappointed with this software… over and over again.
I’ve been stuck at v2.1.1 for nearly a year. When I finally figured out the issue, I’m smack dab in the middle of another issue, rendering the CyberPanel interface unusable for me… and ALL OF MY CLIENTS!!!
I can’t help but feel as though this team truly does not value the trust that we instill within them. Hosting websites is how some of us make our lively hood. We need a control panel interface that’s as reliable as the web server that powers it.
Why is it that the OLS panel for ALWAYS works?! Maybe you two can work a little more closely on these things? Along with having a better user experience, I think it’d make everyone a bit happier. Ultimately, that’d lead to more sales, faster growth, and LiteSpeed earning the respect it deserves.
The current situation is like having a finely tuned Lamborghini engine; only the muffler is loud and keeps falling off, there’s a crack in the windshield, the brakes squeak… and it can’t pass inspection.
I can show potential buyers how fast the car drives ALL DAY LONG! BUT, if they buy it, and can’t get an inspection sticker for the car… well, that’s a Lemon. They want their money back or a working alternative.
It hurts me to say these things… but how many years can I go through this before it’s simply worth my time to purchase LiteSpeed Ent and install it on a cPanel server?!?!