WordPress: Could not save password reset key to database

wordpress-logo-500If you have the error “Could not save password reset key to database.”, more than likely you have one of the following issues:

  • Database server is full (the values cannot be saved to the database due to the file system being 100% full)
  • Database server is read-only (If you use a service such as Amazon Web Service’s RDS your website may be connecting to the read replica instead of the write server)
  • Database cannot make changes to database tables (check the database files can be written to by the user the database service is running as)
  • Temporary folder on your server is not writable (this is the least likely scenario)

I found this problem is not documented well so I blogged my research. Hopefully this helps others searching for a solution.

WordPress Translate System Feedback

I tried to reply with my latest feedback on WordPress.org handling of Translations but sadly my comment was not approved. I’ve tried to have conversations with developers on WordPress’s slack system but instead of considering the problems I raised I quickly got responsive answers.

Here’s my reply so hopefully someone will read it who develops for wordpress.org and will possibly consider some of the ideas I have for fixing the complicated mess that exists today with plugin (and theme) translations on WordPress.org.

A reply to thread Hello Polyglots, First I would like to say

First I want to make this clear, though I am very critical (I am by nature, i am a developer), I support the translation efforts. I know the reaction when someone criticizes the way things are done is perceived as anti WordPress, that is not the case with me. I will call out BS, but again I’m a developer it is in my DNA. I can tell you as a project supervisor, the way this is setup currently will never scale to the 40,000+ plugins, let alone the themes.

I am glad to see for once a thread not get deleted and actually being replied to that points out some of the problems with the way things are working now. Is there now an official way how we can post these issues or is it hit or miss if they get deleted or replied to? I’ve tried to discuss them on here (they get deleted), also on slack I was given answers (that technically did not answer my concerns) rather than have someone listen to my concerns and let me know my concerns would be considered for discussion (responsive vs considerate support).

These are my thoughts as a plugin developer who is not on the WordPress.org core team. Please take my thoughts and ideas into consideration. I think ideas and critical thought from outside WordPress core is necessary from time to time, like any project or application.

* Plugin developers should be trusted with their translations. This would solve a lot of problems. Yes there will be plugin developers who just use Babelfish or Google Translate, but I have an answer for that at the bottom of this reply.

Note: It is common for a company to pay someone to do translation work. In this example, even though I do not speak French, I may have the translations for French that my company paid for to put into my plugin. The current procedure prevents me from doing this translation when I ask for such access simply because the polyglots moderator says I do not speak French. (who owns the plugin and its’ translations?)
* Let plugin developers determine if a translation can happen or not regardless of percentage completed. I know if the developer doesn’t speak that locale language the translations may not be “correct”, but that is how it works today when not using translate.wordpress.org. After all we want to provide some translation rather than none. None is way worse than 50% translated.
* Provide a simple way for plugin developers to add/remove WordPress.org users as translator editors. It should be in the same place we add additional committers to our projects. Then the current method of posting a comment in a particularly specific way can end which is very frustrating. The latest example how to post requesting translators I saw wants you to praise the team in your introduction, this seems rather self-serving to me, almost as if to reinforce the system in place now is a good one.
* Translate editors should be strict. Meaning if I don’t add translator editors to my project, no one I don’t know is approving translations for my plugin without my knowledge. Yes I know the idea is to allow global translation editors can approve translations for whatever plugin, but this brings up legal issues (see my GPL comment below). Perfect world, the plugin author could simply check a box to say “my translator editors only” or “global translators allowed” next to each locale.
*Let plugin developers decide if a translation can even happen. There are situations where I may not want anyone to create a translation into a particular locale. For example, lets say we were going to launch a service in England in April, we may not want a version allowed to be translated until that release.
* Let the plugin developer have the ultimate say about translations. I may have my companies lawyer tell me the translation of a word we use as a trademark in the US cannot be used in France. That that point I as the plugin author need to be able to change that translation (not the translator editor I picked) Ocean90 pointed out some code I can add in PHP to do this but it did not quite answer this specific case, only how i can target locales.
* Ultimately, the translation is part of the plugin and thus the management should be in the control of the plugin developer. Not allowing the plugin developer to have this control means that derived works are technically branches or forks owned by someone else (other than the plugin developer). This brings up legal questions, is a translation where the plugin developer cannot modify or control the translation still part of the original plugin or is it a derived work (where other parts regarding trademarks and copyright need to be modified). With everything falling under GPL here at WordPress.org, it would mean that the inaccessible by the plugin developer translated plugin technically should use a different name and modify the copyright, and give credit to the original plugin developer to make sure not to imply the derived work was his/hers. This problem is solved simply by allowing plugin developers complete control of who can and cannot translate their plugin including themselves (see my first item above).
I believe the scale-able solution is to allow Global Translation Editors the ability to grade translations that have been approved by non global translator editors. This would be viewed as some sort of star rating or grade percentage next to the translation that then the user can decide if it is good or not. That would solve the issue about quality of the translators in a community driven organic way. Also solves the problem if only 90% of the translation is completed, automatically the grade would be at most 90%.
This is what I would like to have access to as a plugin developer. A place in the plugin’s admin page that would list all of the locales in a table form with options:
locale | translator editors | translation allowed by | translation grade | actions
en-us | user1 x, user2 x, … | () global translators () plugin translator editors () plugin author only | 85% of translations accepted by global editors | add translator editor
| – separates columns in table
() – radio button (defaults to global translators)
x – next to user name to remove translator editor
I’ve already had folks reply telling me this cannot be done for random reasons. I beg of the team to instead respond with reasons why it cannot be done, please consider discussing these ideas first.

WordPress GlotPress translate management confusing and is unscalable

Plugins and themes have translators we trust 100%, we’ve forged relationships with these translators over the years. I’m now finding myself telling my friends and colleagues “I trust you, but for some reason WordPress doesn’t trust me with my plugin”. This all stems from the confusing process that is in place now which can be easily fixed giving the plugin and theme owner direct control of their translators.

UPDATE: After speaking with team members on slack about the process, I’ve now learned that the terms used for translation have changed. These new terms are used by the polyglots team but have not been updated on the documentation, hence the confusion. First some terms to clear up…

Translator Editors != Translators – The plan is to let anyone be translators, but only editors could moderate and approve translations.

Translators != Validators – Same as above, translators can make translation recommendations, only validators can also make translations and approve translations.

The new latest process WordPress.org has in place to manage translations for themes and plugins is two fold. First there are “Translation Recommendations”, then there is “Translation Recommendations with Validations”.

Translation Recommendations

If a plugin or theme owner would like users to “recommend translations”, all the user has to do is create an account on wordpress.org. Anyone with an account on WordPress.org has permission to “recommend” translations for WordPress core, as well as any theme or plugin. I am sure this will not last long, once malicious users get their hands on this the WP.org team will be forced to chance this policy. I like the spirit of this though, but they do not make this clear in the documentation. The way it is written currently and the terms used “translator” and “translator editor” implied to me that once the user created an account they still had to be added as a “translator editor”, but that is why they’ve changed the terms.

Translation Recommendations are placed in a queue to be confirmed or marked fuzzy by translation moderators (Translation Editors or Validators). Plugin and theme developers can request specific users to be validators for specific locales.

Translation Recommendations with Validations

If a theme or plugin owner wants specific users to “translate and validate” translations in particular locales, a request must be made in this comment thread (must include the word “request” in the tag field otherwise your requests go into a black hole) and request users to be “validators” for specific locales for your plugin/theme. Specifically you need to include the following in your posting:

Your @WP.org-user-name
locale code (en or en_US) – @WP.org-User-Name – slug name of your plugin

As of current, plugin/theme owners can only request validator users and must wait for the users to be approved. There is no simple add option like that for adding committers to your project. It appears they are approving all requests, but the process is taking very long to do so. As I understand it, they are not rejecting requests, plugin and theme owners can rest assured they have control of their translations if they request it.

How Translation should be for themes and plugins

Plugin and theme owners should have control who can translate their plugin/theme, which languages can be translated, and be able to add remove translators. Plugin and theme owners should be able to add themselves as validators for any or all locales as well.

Plugin and theme owners should have the ability to decide if a translator has “full translation control” (translator and validator) or if their translations should be moderated by someone else (other valdiators). I like the idea of anyone making translation recommendations, but there should be management screen with setting in a grid view where we as plugin/theme owners can decide if  locale can or cannot be translated as well as enable/disable if translation recommendations are from anyone, or allow fur adding specific users. A grid where the columns are “locale”, “enable/disable (enabled by default”, “Allow anyone to recommend translations”, “recommend translators”, and “translation validators”. Each row would have the locale. The cells within the “recommend translators” and “translation validators” would have a textbox with an add button to add validators, as well as list the current validators with a button to remove them.

These proposed options above would allow a theme or plugin owner to add someone as a translator exclusively, they will not have to be distracted by anyone on WordPress.org making recommendations. The plugin author can also decide if a particular locale should be available or not for their plugin. Defaults though should follow what WordPress.org has in place now which encourages anyone to contribute.

The idea that plugin and theme developers cannot control the process, and that translations happen without the interaction of the theme/plugin developer in my mind violates GPL and certainly creates issues for copyrights. Luckily, this is not the case. Currently the polyglots team is changing “terms” for translation management which lies the confusion.

Why do Theme and Plugin Developers need to be moderators of their translations?

As creators of a product, albeit free and open source, there are situations where words, phrases cannot or should not be translated. For example, a website name (not the URL), plugin author should be able to decide if it remains as-is in some languages but can be translated in others. Many of these terms are copyrighted and in other cases, are technology terms that if translated, may cause more confusion. It should be up to the plugin/theme owner to have final say.

There is a way in the code to prevent some parts of strings to not be translated, but it does not control this down to the specific locales.

Another problem comes with companies who have translators on staff and can do translations. Our company has to add our employees (which can change over time) to have access to translate. What was a simple here’s the po file go to work operation has now turned into “I have to wait for WordPress.org to approve our  our employee fluent in French to be a validator for our plugin”.

Plugin and theme authors should be able to decide which languages are translated. Though I wouldn’t use such a feature, I could see a company like Facebook prevent translations for certain languages/locales until they have the language locale added to their service.

Current process does not scale

The current process at translate.wordpress.org is not going to scale to 40,000 plugins with 50+ translation possibilities each. I don’t care how many volunteers there may be helping with translations, adding a comment to a blog post it’s not going to work, we’ll see some plugins receive priority moderation (validating) over others, which will more than likely be influenced politically.

At some point a page for plugin owners wil lneed to be created that lets them pick a locale and enter a wp.org user and click ‘Add’. The faster and smoother they can make this process the less confusing it will be for all involved, and the faster new translators will start contributing.

I’m already wasted a few weeks trying to figure out how the process works, which appears is still being figured out, which also bothers me that these problems were not even discussed or thought about.

I want centralized translation to work

Do not read above and believe that I am anti WordPress or anti translation. I want this to work. To not trust the plugin / theme authors with the responsibility of controlling their translations is not only wrong, it poses the problems I describe above. This process needs to be fixed ASAP.

I would ask that you do not post comments here. Instead, I’ve opened a trac ticket requesting that this process be changed. Please comment there so WordPress translate team can read your concerns about how theme and plugin translations are currently managed. Update: My Trac ticket has been closed, feel free to comment below.

GetID3 analyze() function new file size parameter

You can now read ID3 (media file headers) information from mp3 and other media files using GetID3 library without having the entire media file present. The new 2nd parameter to the analyze() member function allows you to detect play time duration with only a small portion of the file present.

Years ago I added this code to the versions of the getid3 library we packaged with the Blubrry PowerPress podcasting plugin. I’ve submitted this code to the getid3 project so everyone can benefit. As of GetID3 v1.9.10,  you can now pass a second optional parameter specifying the total file size. This parameter sets the file size value in the getid3 object, skipping the need for the library call the filesize() function.

This is the secret sauce that allows PowerPress to detect the file size and duration information from a media URL of any size in only a few seconds.


The new parameter only works if the following are true:

  • Have enough of the beginning of the media file that includes all of the ID3 header information. For a typical mp3 the first 1MB should suffice, though if there is a large image within your ID3 tags then you may need more than 1MB.
  • Have the total file size in bytes.
  • The mp3 file is using a constant bit rate. This must be true for podcasting, and highly recommended if the media is to be played within web browsers. Please read this page for details regarding VBR and podcasting.

Example Usage

// First 1MB of episode-1.mp3 that is 32,540,576 bytes
// (approximately 32MB)
$media_first1mb = '/tmp/episode-1-partial.mp3
$media_file_size = 32540576;
$getID3 = new getID3;
$FileInfo = $getID3->analyze( $media_first1mb, $media_file_size );

You can use a HTTP/1.1 byte range request to download the first 1MB of a media file, as well as a HTTP HEAD request to get the complete file length (file byte size).

Byte range requests and HEAD requests are safe to use for podcasting. If a service does not allow HEAD requests or accepts byte range requests, then they will have bigger issues to deal with as these features are required by iTunes.

Blubrry PowerPress podcasting plugin has been using this logic to detect mp3 (audio/mpeg), m4a (audio/x-m4a), mp4 (video/mp4), m4v (video/x-m4v), oga (audio/ogg) media since 2008.

Not all media formats support this option. You should test any format not mentioned above. For example, ogg Vorbis audio works, ogg Speex audio does not.