Far too often I've seen people manually saving, creating and writing to files within their plugins when easier ways exist. We can thank our PocketMine developer overlords for creating the pocketmine/utils/Config class, it's a great way to handle data saving within a plugin. The first thing you need to do when using config files is to make sure your plugin’s data folder exists, we can easily achieve this from our PluginBase class: PHP: @mkdir($this->getDataFolder()); Next, we need to create or save the resource, we can achieve this easily with one line of code from our main class: PHP: $this->saveResource("MyConfig.yml"); I usually save all my resources in the PluginBase::onEnable() method to make sure they exist every time my plugin is enabled. You can also skip the manual data folder creation by creating default resources in your plugin’s /resources/ directory and calling the PluginBase::saveResource() method. The next thing you need to do is figure out when and how you will be accessing your config, if you are only using your config for settings or a simple data storage solution I'd recommend creating a new config instance and storing it in a class property on the relevant class: PHP: $this->myConfig = new Config($this->getDataFolder() . "MyConfig.yml", Config::YAML); This code will store a new config instance into a class property that we can easily access at any time so we can easily save and read data. It is also assumed that you are putting this in your PluginBase::onEnable() function. Spoiler: An example You should end up with something that looks similar to this: PHP: namespace your\namespace;use pocketmine\plugin\PluginBase;use pocketmine\utils\Config;class MyClass extends PluginBase { /** @var Config */ public $myConfig; public function onEnable() { @mkdir($this->getDataFolder()); $this->saveResource("MyConfig.yml"); $this->myConfig = new Config($this->getDataFolder() . "MyConfig.yml", Config::YAML); }} Configs are a useful way to handle data saving through plugins but they are not always necessary; if you just plan on calling Config::getAll() to return all the data, you're better off calling yaml_parse() or json_decode() directly on the data to cut all the useless function calls from a config object.
I propose the addition of a global config API, or the invention of a global config library that helps plugins parse config contents. For example, a config entry 'Foo $player bar' should resolve to "Foo SOFe bar" given the context with a player object of "SOFe". This API can be extended with more plugins, e.g. $money for money in economy plugins.
Actually, data folder is implicitly created before saveResource() call. Also, prefer using config.yml, $this->saveDefaultConfig() and $this->getConfig().
Only if you're saving a resource from the /resources folder of a plugin. https://github.com/pmmp/PocketMine-MP/blob/master/src/pocketmine/plugin/PluginBase.php#L200L202 These methods simplify the process but after all, there is only one default config. This thread allows users to see what goes on behind these methods and lets them replicate it without blindly calling the functions.
What is the relationship between this and my post? It only checks if the resource is available from the phar, regardless it's created in data folder or not. Recommend adding them too
Where did I mention a data folder? I am talking about the resources that are packaged with a phar (/resources directory). The link I provided clearly shows that if the resource you are saving is not present in the phar, the plugins data folder is not created; hence the need to create it yourself, if you're creating a config completely from code (not saving a copy of a predefined resource packaged within the archive).
Use an array: PHP: $arr = ["one", "two", "three"]; // create array$arr[] = "four"; // append to array$config->set("GetMe", $arr);
PHP: $this->myConfig = new Config($this->getDataFolder() . "MyConfig.yml", Config::YAML); Its easyer to say 2 instead of Config::YAML PHP: $this->myConfig = new Config($this->getDataFolder() . "MyConfig.yml", 2);
What does that say for readability? What does the 2 stands for? And that alone is big issue, but not the main one. What if the constant is changed in source code? What if number 2 no longer represents the YAML encoding?
the name is pretty self-explanatory, it checks if a specific key exists in the config and returns true if it does, false otherwise example: PHP: if($config->exists("some_key", false)){ //do something here} the first parameter is the key you want to check if it exists, the second parameter is whether to make the search case insensitive example PHP: // let's imagine there's a key in the config called join_message// and we search for JOIN_MESSAGE// if we set the second parameter to false, the exists function would return false thus the code inside the if statement won't runif($config->exists("JOIN_MESSAGE", false)){ $this->getLogger()->info("key exists"); // it won't print "key exists" on the console}// let's try setting the second parameter to trueif($config->exists("JOIN_MESSAGE", true)){ $this->getLogger()->info("key exists"); // it will print "key exists" on the console}
Hey, sorry, second question : in a yaml config, how to use under cotegories : Code: category1: category2: value In this case, how to take category2's value ?