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

I am unfortunately unable to setup a test environment to see if I can replicate the issue. However, the messages that you provided begin with the keyword "Notice". Although ignoring Notices is not advised, Notice messages are considered to be soft errors that will not prevent the PHP script from completing execution. Perhaps those Notice messages are unrelated to the Password Reset failure. Were you able to send mail via FluxCP before you submitted this question? You might need to make corrections in the FluxCP configuration.

That web tool looks nice. It seems to be a Laravel PHP solution. According to the README.md, you only need to make sure both PHP5 and the PDO driver are installed. The PHP5 and PDO driver installation steps depend on your webserver environment. The ROChargenPHP software itself appears to be a drop-in installation. There should be no installer to run. ( See http://www.example.com/ROChargenPHP/... ) When reviewing the Custom display section, the usage steps appear to be nothing more than creating a CharacterRender object, configuring variables that customize the character, and then executing commands to render the image. The final result should be a URL that outputs an image/png. For more information on the image output process, visit the PHP imagepng documentation. There might be other hurdles to overcome, but I am sure the answers will become obvious once you stage the ROChargenPHP software.

WooZy here - I am new to the scene, and late by many years it seems. I have never deployed a Ragnarok Online private server. The rAthena software is helping me break the ice. I am interested in improving my Systems Engineering skillset and am focused on maintaining cloud environments. I will admit, deploying the rAthena software is challenging for me. It appears that I am missing generations worth of important Ragnarok Online development knowledge. If I were to contribute anything to this community, I hope that I can provide a process to simplify deployment. Thank you all for having me. I am looking forward to learning and spending time with the rAthena community.

You are missing a great deal of information in your question. Review the following configuration files and update the public and bind IP address properties: - conf/char_athena.conf - conf/login_athena.conf - conf/map_athena.conf If you are hosting from a residential location, you might want to look into forwarding any necessary ports to your rAthena server.

I managed to compile an unmodified rAthena release within an Ubuntu 20.04.3 LTS (Focal Fossa) environment using gcc-9.

You changed the mode for every object in your webroot to "777". That is a security risk and you should reconsider performing that action as a solution. Your webroot directory and content permissions are wide open. Instead, change permissions only for the files and directories that require it.