You can try to change log_bin_trust_function_creators; however, there is an alternative approach that seems more appropriate when you consider the meaning of that variable:
It controls whether stored function creators can be trusted not to create stored functions that will cause unsafe events to be written to the binary log.
A setting of 0 also enforces the restriction that a function must be declared with the DETERMINISTIC characteristic, or with the READS SQL DATA or NO SQL characteristic. If the variable is set to 1, MySQL does not enforce these restrictions on stored function creation.
All that option does is assume that you know what you are doing, without making you assert that you do by using one of the three characteristics in your CREATE statement... but if you don't properly declare the function, you may miss out on potential optimizations.
misdeclaring a routine might affect results or affect performance
Taken together, this implies that the most correct approach is to declare your stored functions with DETERMINISTIC or READS SQL DATA or NO SQL as appropriate, and, if these do not correctly describe your function's behavior, then your function still may result in unsafe statements being written to the binary log, because these options are also "trusted:"
Assessment of the nature of a routine is based on the “honesty” of the creator: MySQL does not check that a routine declared DETERMINISTIC is free of statements that produce nondeterministic results.
Curious aside: astute observers will note that I omitted something from the documentation's description:
If set to 0 (the default), users are not permitted to create or alter stored functions unless they have the SUPER privilege in addition to the CREATE ROUTINE or ALTER ROUTINE privilege.
Since nobody gets SUPER in RDS, and assuming this is not an error in the official documentation, this seems like it must be an AWS customization of MySQL behavior.
Of the three, I prefer repair!
Looks like your phpMyAdmin was installed by the package manager, so the first thing to try is reconfiguring it. sudo dpkg-reconfigure phpmyadmin should accomplish that. Hopefully that will fix the error message you got that "phpmyadmin is broken or not fully installed" -- or if not, at least provide you with a more helpful message.
You may have other broken packages or missing dependencies, which you can try to fix with sudo aptitude -f. That will attempt to fix any broken packages.
I'm not really sure about your terminal error message. It appears that the /bin/ directory (which contains many of your system commands like ls, kill, mkdir, and many more), isn't in the list of directories used when looking for a command (the "path"). I'm hopeful that the aptitude -f will fix this too, because otherwise something really strange (and unrelated) happened to your bash configuration file.
Note that, while these are reasonably safe commands, I'm not responsible if your system explodes.
Best Answer
Plesk via GoDaddy does not allow you to have admin privileges over phpMyAdmin. This seems to be a result of shared hosting. In order to do any action that does require that privilege you have to use work arounds or third party software.
I answered this here as it seems that this information cannot be found on the Plesk or goDaddy forums.