changedname

More information is needed to provide a proper answer. The first item I noticed is that 400 response to the POST action. Review the following documentation: 400 Bad Request A request made by the client was rejected by the server because it was perceived to be an error. Could you please explain what actions are taking place to trigger the error messages? The second item that I noticed is the "/emblem/upload" POST action. We need to understand what previous troubleshooting steps were taken. - Are you uploading a file directly or uploading from a remote location? - What file are you uploading? - How many users are triggering the error message? - Do any other files upload properly? Of course, the questions above assume that an attempt to upload a file was made.

Before setting 777 permissions on directories that are accessible to the public, did you first confirm the Ownership? Your webserver process should be running under a non-root user, such as apache, nobody, or www-data. Run the following BASH command to find the appropriate user: ps aux | egrep '(apache|httpd)' The "data/" and "data/tmp/" directories on my FluxCP instance are not set to hold 777, and they never will.

My response expands upon the answer Kakaroto provided. Setting the configuration "$showExceptions = false;" within the file "conf/error.php" will only turn off the FluxCP error output script. If PHP is not configured to silence error reporting, information such as your document root absolute path could still display. The larger concern is that an error message is exposing your document root absolute path. The pathing information provides visitors with an idea of how your website is hosted. Information examples include: - Are you using a multi-tenant hosting Control Panel solution, such as cPanel or DirectAdmin? - What is the hosting account or server Username? (A personal computer might expose your real name.) - Are there other directories of interest within the absolute path? (Relative pathing might allow unintended access to a file or software.) You will not be able to hide your webserver public IP address without using advanced techniques. I will not go over such techniques as it would take an unreasonable amount of time and effort to explain. Please review this easy to use DNS tool to see a demonstration: DNS Lookup Cloudflare or other similar services should be able to provide any required DDoS protection.

Just to be clear, did you mean to say "error message" instead of "mistake"? It would be helpful to have an error message. There is currently not enough information to resolve your issue. If you made no changes to the source code, account passwords should be stored in cleartext within the database. Open the database in your SQL browser of choice and copy the password found within the login table.

Just to be clear, it seems that the rAthena and Database servers are on one host and the Website server is on another host. When attempting to connect the website Control Panel to the Database server, are you given any error messages? Potential issues include: - Host 1 and/or Host 2 firewalls are blocking access to the Database port. - The website Control Panel was configured with the incorrect database access credentials. - The Database User was not granted privileges that allow access from the Webserver IP address. - The Database service is not running.

I have not heard of Open Server Panel (OSPanel) before, and not many people seem use it. The OSPanel forum statistics currently advertise, "Total Users: 6595". I recommend that you instead learn how to use WAMP or XAMPP, since you seem to be a Windows user. Otherwise, you can try typing an IP address within the IP-address of server drop-down field and click on the Save button. Good luck!

I apologize for such a late response to your January 24, 2018 question, but I only recently joined the rAthena forum. The error message provided seems to be an unhandled Syntax Error: Recoverable fatal error: Object of class Flux_Config could not be converted to string myserver.com/fluxcp/addons/fluxbb/themes/default/fluxbb/index.php on line 44 I would recommend submitting a GitLab Issue to the repository, however the FluxBB integration project was abandoned (9) months prior to your question. I do not recommend using the FluxBB forum software as the latest update mentions a plan on dropping support for PHP 4. PHP 4 hit end-of-life (EOL) on August 7th, 2008. A more modern forum software should better serve your community. Just an opinion: Integrating forum software with a private server Control Panel might be unnecessary. Most gamers communicate through Discord now, a third-party that does not officially support integration with FluxCP. Forum software that is not integrate with FluxCP would behave the same way as Discord. Users could claim to be whoever they wish. If rAthena Server Administrators truly need to connect an rAthena account to activity posted in a forum, IP address history should serve as a useful investigation tool.

You did not mention the results of any previously made troubleshooting attempts. More information is required to resolve this issue. I have compressed the PHP source code snippet to better explain my claim: $data = $CACHE->get('MVPCard', FALSE, 1440); $total = array(); if (!$data ) { $total = array(); foreach( $GV->Global_MVPCard as $val ) { $consult = "{{SELECT_STATEMENT}}"; $filled_array = array_fill(0,10, $val[0]); $result = $DB->execute($consult, $filled_array); $row = $result->fetch(); $DB->free($result); array_push($total, [ 'id' => $val[0], 'total' => $row['total'] ]); } $CACHE->put('MVPCard', $total); $data = $CACHE->get('MVPCard', FALSE, 1440); } I recommend that you isolate and double-check the return values for each of the following: - Line 1: "$data = $CACHE->get('MVPCard', FALSE, 1440);" Cached data might contain NULL values. - Line 6: "foreach( $GV->Global_MVPCard as $val ) {" Does $GV->Global_MVPCard contain the expected values? - Line 10: "$row = $result->fetch();" Is the MySQL query fetching NULL values from the database? Running the PHP source code snippet through a PHP Syntax Checker returned no errors. I would consider the presence of a Logic Error or missing data entries.

It would be difficult to troubleshoot this issue without looking at the Theme source code. Taking a guess, there is probably a Character Set conflict. Review the following W3Schools link: https://www.w3schools.com/html/html_charset.asp What language are you attempting to use? Do you know which Character Set is configured for your website and Theme? Try adding the following meta tag to the document head in your HTML source code: <meta charset="UTF-8">

PHP 4 style constructors were deprecated in PHP 7. However, the warning messages should not prevent your theme scripts from executing. Perhaps there is another issue elsewhere. Did you check for error messages? https://stackoverflow.com/questions/1053424/how-do-i-get-php-errors-to-display?rq=1 You could modify the theme source code to resolve any outstanding issues or suppress the deprecation warning messages.

Check the "./themes/default/main/sidebar.php" file on line (45) : <th class="menuitem"><strong><?php echo htmlspecialchars(Flux::message($menuCategory)) ?></strong></th> </tr> <?php foreach ($menus as $menuItem): ?> <tr> <td class="menuitem"> <a href="<?php echo $menuItem['url'] ?>"<?php if ($menuItem['module'] == 'account' && $menuItem['action'] == 'logout') echo ' onclick="return confirm(\'Are you sure you want to logout?\')"' ?>> <span><?php echo htmlspecialchars(Flux::message($menuItem['name'])) ?></span> </a> </td> </tr The Anchor behavior appears to be hardcoded, affecting all menuItem objects the same. See the following W3schools entry: https://www.w3schools.com/tags/att_a_target.asp The (target="_blank") Attribute would need to go in here. You will need to develop logic to check for the appropriate module and action, otherwise all links will open in a new tab.

It appears that the database query handling the account registration did not return any results. Check the "./modules/account/create.php" file: // Woohoo! Register ;) $result = $server->loginServer->register($username, $password, $confirm, $email, $email2, $gender, $birthdate, $code); if ($result) { ... } else { exit('Uh oh, what happened?'); } Check the database "login" Table. Do you see the newly registered account? Make sure the FluxCP software has access to the database "login" Table, and that the associated MySQL user holds the appropriate privileges.

I am not sure if support for a player referral system is available. If no referral plug-ins exist, you should be able to code a solution without much issue. You could capture "referral codes" by passing them through a PHP script via the provided URL. Check out the PHP documentation for the $_GET array. Record the visiting IP address and referral code within the database, then use IP associations to track the users who clicked on a link.

I am not sure if Web Support is the proper sub-forum for your question. Perhaps you would find more luck submitting the question to Web Requests, or asking in the Discord #fluxcp channel. Did you have a support issue with some web software?

Please do not execute "chmod -R 777" against anything open to the public internet. That command grants all privileges to all users to all files and directories, exposing the webserver to potential exploits. Run the following command on your CentOS 8 server: yum install php-mysqlnd