GP_Route_Login redirects to a URL that wp_logout_url() returns. That URL is HTML encoded, so query parameters, especially _wpnonce, will not get read right.

Nonces won't help, if they never get printed to a web page, so instead of using the logout route, the logout link should point directly to wp-login.php using the wp_logout_url() function. Or, if the route is deemed to be worth saving, the logout link should have a nonce in it and the final WordPress logout url should be manually constructed.

As per #5, the plan is for the GlotPress plugin to no longer have a separate users and usermeta, but to use WordPress' tables as well as all the WordPress authentication awesomeness. If someone really doesn't want to mix their GlotPress users with the other users of their site, they can setup an independent WordPress install just for GlotPress.

GlotPress standalone can be setup to share a WordPress install's users and usermeta tables by defining the CUSTOM_USER_TABLE and CUSTOM_USER_META_TABLE constants. If that's the case for your GlotPress standalone install, then no migration is necessary.

If your standalone GlotPress install doesn't share the users and usermeta tables with a WordPress install, you will need to migrate the GlotPress users and usermeta table to the WordPress users and usermeta tables.

I propose that upon plugin activation, we detect if the GlotPress user and usermeta tables already exist and provide a dashboard-wide notice something to the effect...

Import GlotPress Users? — We've detected users from a GlotPress standalone install. The GlotPress plugin no longer uses those tables. Would you like to import the users and their data into WordPress?
[ Yes ] [ No ]

If they choose "No", we should permanently dismiss the notice. If they choose "Yes", we should take them to Tools > Import where they can choose to install a "GlotPress Users" plugin to carry out the import.

backpress_set_cookie() and backpress_gmt_strtotime() are the only functions which are prefixed with backpress_, defined in gp-includes/misc.php: https://github.com/deliciousbrains/GlotPress/blob/d6d64318936885320a3e9412a3ce3c9ed28cd764/gp-includes/misc.php#L459-L484.

We should check if they can be replaced with WP function. If not, then we should prefix them with gp_.

If you go to Locales and then select a language, the link at the bottom of the page for "All projects" doesn't use gp_url() in the gp_link() call which can generate an incorrect url if GlotPress isn't in the root.

Add breadcrumbs display to the projects and Locales pages for consistency and to make sure any gp_notices display correctly.

In order to unify, we should make these WP-CLI commands, rather than directly invoked scripts.

Unfortunately, WP-CLI doesn't support short options (ala -o xyz), so this needs a proper rewrite.

Working on this right now. :)

Clean up the root dir a bit

The line exists in gp-settings.php https://github.com/deliciousbrains/GlotPress/blob/ee8353be2b124d4339c9cb1d06a03b081eb6d4ee/gp-settings.php#L22 and was introduced in https://glotpress.trac.wordpress.org/changeset/303.

Could this break other plugins/themes or WordPress? Is it still needed? Needs a little review.

I think we should provide a hook which plugins can use to bootstrap their code. This would reduce the need for is_plugin_active() checks to prevent fatal errors.

Maybe gp_init and/or gp_loaded?

Deleting a project or a glossary item (at least) will result into a PHP notice:

Notice: wpdb::prepare was called incorrectly. The query argument of wpdb::prepare() must have a placeholder.

sql_from_conditions() in GP_Thing creates the SQL WHERE clauses by concatenation. There are at least two ways to solve the issue. Either the function must be fixed to instead place parameters or calling $wpdb->prepare on such SQL queries should be skipped.

How much should we worry about backwards compatibility?

When it comes to plugins, I don't think we should worry at all. All GlotPress plugins will need to be converted to WordPress plugins anyways as per #7.

Themes might be a different story. I'm sure lots of people have heavily customized their GlotPress themes, so it would be nice to allow people to switch to the GlotPress plugin from a standalone install using their existing GlotPress theme. Would be great to hear from people who have a custom GlotPress theme...

Currently GlotPress stores options as gp_option in the meta table. We should replace this with the options API from WordPress.

Proposal:

• gp_update_option() => update_option()
• gp_get_option() => get_option()
• gp_delete_option() => delete_option()
• gp_cache_all_options() => Remove
• gp_get_option_from_db() => Remove
• gp_option() => Remove

There's no point having GlotPress plugins when WordPress already has a plugin system. Let's rip out the GlotPress plugin system and convert all the hooks to WordPress hooks.

Importing originals in to a project redirects the user back to the import page, which probably isn't the right choice as they are unlikely to be importing more originals.

Instead the redirect should take them back to the project page.

As per https://make.wordpress.org/core/handbook/best-practices/inline-documentation-standards/php/#4-hooks-actions-and-filters.

The GlotPress action/filters currently are a mix of "action_desc_here" and "gp_action_desc_here".

To avoid conflicts with other WordPress plugins, we should prefix all action/filters in GlotPress with "gp_" (that are GlotPress action/filters of course, not WordPress action/filters the plugin will use).

GP uses a js/no-js class to determine if javascript is active on the client browser. This was accomplished by using a custom body_class() function which was replaced with WP's body_class() function but the 'no-js' class was not migrated over.

Since no-js doesn't exist it is never replaced with the js class during the page load.

Tried a few times to import the WPMDB .mo file, but keep getting timeouts:

[28-Aug-2015 23:55:46 UTC] PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /.../glotpress/gp-includes/strings.php on line 58
[28-Aug-2015 23:55:46 UTC] PHP Stack trace:
[28-Aug-2015 23:55:46 UTC] PHP   1. {main}() /.../glotpress-plugin.dev/index.php:0
[28-Aug-2015 23:55:46 UTC] PHP   2. require() /.../glotpress-plugin.dev/index.php:17
[28-Aug-2015 23:55:46 UTC] PHP   3. require_once() /.../glotpress-plugin.dev/wp-blog-header.php:16
[28-Aug-2015 23:55:46 UTC] PHP   4. do_action() /.../glotpress-plugin.dev/wp-includes/template-loader.php:12
[28-Aug-2015 23:55:46 UTC] PHP   5. call_user_func_array:{/.../glotpress-plugin.dev/wp-includes/plugin.php:496}() /.../glotpress-plugin.dev/wp-includes/plugin.php:496
[28-Aug-2015 23:55:46 UTC] PHP   6. gp_run_route() /.../glotpress-plugin.dev/wp-includes/plugin.php:496
[28-Aug-2015 23:55:46 UTC] PHP   7. GP_Router->route() /.../glotpress/gp-settings.php:170
[28-Aug-2015 23:55:46 UTC] PHP   8. call_user_func_array:{/.../glotpress/gp-includes/router.php:168}() /.../glotpress/gp-includes/router.php:168
[28-Aug-2015 23:55:46 UTC] PHP   9. GP_Route_Project->import_originals_post() /.../glotpress/gp-includes/router.php:168
[28-Aug-2015 23:55:46 UTC] PHP  10. GP_Original->import_for_project() /.../glotpress/gp-includes/routes/project.php:115
[28-Aug-2015 23:55:46 UTC] PHP  11. GP_Original->closest_original() /.../glotpress/gp-includes/things/original.php:145
[28-Aug-2015 23:55:46 UTC] PHP  12. gp_string_similarity() /.../glotpress/gp-includes/things/original.php:226
[28-Aug-2015 23:55:46 UTC] PHP  13. gp_levenshtein() /.../glotpress/gp-includes/strings.php:98
[28-Aug-2015 23:55:46 UTC] PHP  14. gp_substr() /.../glotpress/gp-includes/strings.php:139

There's currently a route to delete projects that works but no UI to access it. A UI should be added.

...I'm assuming they need some tweaking to run as a plugin with WP.

When you edit a translation string and press the "Add translation" button, the "Saving" popup is displayed but never completes. The translation is not saved.

This is because wp_localize_script() on the editor page has the wrong handle name for the enqueued script (looks like it was prepended with gp- during on the enqueuer call during initial change to a plugin but not updated on the localize call).

We're currently using a separate table for user permissions, instead we should convert to using WP roles and capabilities. Permissions should be stored in the usermeta table.

This will likely need tackling as part of PR https://github.com/deliciousbrains/GlotPress/pull/20

The following functions are no longer needed:

• _gp_get_secret_key
• _gp_get_salt
• gp_salt
• gp_hash
• gp_generate_password

All from /gp-includes/misc.php

If WordPress is installed in a subdirectory (like http://site/wp) it only returns a 404 error.

This is because router.php has the following code on line 136:

if ( $url_base && ! gp_startswith( $_SERVER['REQUEST_URI'], $url_base ) ) {

The server request URI is /wp/glotpress but the $url_base is just /glotpress.

$gpdb->insert() does some additional processing that is not done in $wpdb->insert().

Particularly troublesome is the fact that it substitutes NULL for data values that are not set, which GlotPress then checks for in various places in SELECT statements.

For example, start a new project and import some originals, if no context or plural are set, each original will have 'context' and 'plural' set to an empty string not NULL.

Then create a translation set and import some strings, no values are imported as the import code try's to find the originals with NULL values in the 'context' and 'plural' fields.

There are a couple of solutions off the top of my head:

1. Continue to use $gpdb but instead of using the backpress version create our own that is an extension of $wpdb.
2. Find all the select statements that check for null and replace/add an empty string to them as well.

Any one else have any thoughts on this?

I've added this to the 1.0 milestone for now, but it's up for debate. WordPress core will be supporting PHP 7 when it is released next month.

Kinda makes sense given the purpose of the plugin itself!

gp_limit_for_page() in https://github.com/deliciousbrains/GlotPress/blob/d6d64318936885320a3e9412a3ce3c9ed28cd764/gp-includes/misc.php#L128-L137 looks dangerous and should be removed. It doesn't get used anymore.

Introduced in https://glotpress.trac.wordpress.org/changeset/78

Previously: #16

• Placeholders aren't explained in a translator comments
• The use of _n() is wrong in some cases, like _n('One translation rejected.', '%d translations rejected.', $ok, 'glotpress' ), $ok );
• Strings like __( 'edit', 'glotpress' ) should get a context: _x( 'edit', 'glossary', 'glotpress' )
• esc_attr( __( ) ) should be esc_attr__( )
• echo _x( ) should be _ex( )

Note: Each point can have its own PR.

GlotPress links to URLs without trailing slashes, but WordPress redirects those URLs with trailing slashes. This happens even with permalinks set to have no trailing slashes. This is a problem because most clicks make two requests to PHP.

In redirect_canonical(), WordPress thinks is_front_page() is true. That is because $wp_query->is_home is set to true if no other type of page is detected. By setting that to false through a filter would probably solve the issue of redirects, assuming one sets the permalinks with no trailing slashes to match GlotPress's current behavior. But in addition to that, URLs GlotPress prints out should honor the permalink structure of WordPress.

This also effects the body class value, which states every GlotPress page is "home" and "blog" when they obviously are not.

There's no reason to have a global variable for $gpdb when it's simply an alias to $wpdb.

We need a readme.txt file for when we submit to the plugin directory.

...to make it easier for those moving from GlotPress standalone install.

wp-includes/strings.php contains these functions related to multibyte string handling:

• gp_strtolower()
• gp_strlen()
• gp_stripos()
• gp_substr()

All of which are wrappers for functions that exists in PHP 5.2 or lower with a fallback for older versions. Thus, these functions could be deleted after replacing their usage elsewhere in the plugin with direct access to native functions.

Additionally, gp_add_slash() is not used at all and has a WP equivalent in trailingslashit().

Glotpres displays notices when actions such as creating a new project or importing originals have been completed, but they aren't showing up in this version.

The current database update code is contained in the plugin activation hook, however this hook is not fired when a plugin upgrade occurs.

This code should be moved outside of the activation function.

The info there is outdated and it belongs somewhere else, inline docs or a devhub.

PR #13 moved all the css files to assets/css, but the upstream merges from #27 & #28 added a css file which of course was still in /css.

This is a pretty huge change that's not essential for a first plugin release, so bumping it to the future.

I think gp-settings.php should only define constants/globals, include/require files and register plugin (de)activation hooks.

I'd also like to see all add_action() and add_filter() calls to be added to gp-includes/default-filters.php. (Related core ticket: #30947

Thoughts? Objections?

For dc29852 we need to flush the rewrite rules.

gp_time_since() is only used on the profile page, see https://github.com/deliciousbrains/GlotPress/blob/d6d64318936885320a3e9412a3ce3c9ed28cd764/gp-templates/profile-public.php#L43.

It still uses wp_enqueue_script(), should be gp_enqueue_script().

Add GlotPress menu. Ability to administer projects, translation sets etc.

I think this can be achieved by allowing define( 'GP_URL_BASE', '' );. This may already work (I haven't tested it) but I doubt it.

WordPress: https://github.com/WordPress/WordPress/blob/4204afdd402533586cb54e5ca06e5b0d0e1fc365/wp-includes/pluggable.php#L1197-L1231

GlotPress: https://github.com/deliciousbrains/GlotPress/blob/ee8353be2b124d4339c9cb1d06a03b081eb6d4ee/gp-includes/misc.php#L109-L126

Actually the only difference are the filter names… global $is_IIS; doesn't exist in GP, see the note.

Implement after https://github.com/deliciousbrains/GlotPress/pull/13 is merged, and use Grunt from deliciousbrains/glotpress-old@52fe969