MLP - The Multi-Lingual Publishing Pack

Bloke · 2013-01-20 22:33:50

jstubbs wrote:

Even after downgrading to 4.5.2 I’m seeing problems on one MLP install. Article edits are not getting saved to the DB at all. No idea why so far.

After spending some debug time with MLP a couple of days ago as adriano32 noticed, I’ve found the root cause of a few of the problems. The ‘Array to string conversion’ bug has been squashed and I found a couple of little oversights that may be the cause of the saving problem, but I’ not sure as I can’t replicate the problem on a vanilla install on 4.5.4 + MLP. I also liked adriano32’s default lang string solution so I pushed that to the master branch too. Thanks!

The crux of a lot of the issues like the one kees-b had with not being able to uncheck any of the articles is that MySQL only permits fulltext searches on MyISAM database types. MySQL has a bunch of weird and wonderful database types for different styles of application. MLP didn’t universally specify which to use so it’s given the one as defined in the server’s config file when it comes time to create temporary tables and stuff. A few hosts have recently switched over to using InnoDB as default so when MLP asks to create a temporary table to do some stuff, it may get an InnoDB table; it then tries to create a table with a fulltext index and B-O-O-M (though it crashes silently because errors were suppressed — I’m not generally a fan of this practice so I’ll gradually stamp it out as things evolve).

Long story short I don’t yet know why some people can’t save articles, but it might have something to do with the type of database that your host uses by default. If you can query your DB and/or config files and it indicates InnoDB (or something other than MyISAM) then feel free to try the master branch from github and see if it solves things. Note that because this isn’t yet a full release, the changes to the l10n plugin have only been done in the plugin/sources folder so if you want the full experience with adriano32’s default lang patch, you’ll need to copy and paste the source code over the top of the existing l10n plugin from the Admin->Plugins panel. Back up everything first of course, as normal.

I’ll do some more testing soon and see if I can get to the bottom of the saving problems, but unless I can catch it in the act I’m stabbing in the dark. If anybody has any further insight or any Firebug output that you think might be of use to track it down during the AJAX save, pease let me know.

adriano32 · 2013-01-21 00:43:24

Hi, Bloke.

About default lang string solution: i have looked again over my suggestion and your patch at github, and i have one question and one improvement.

Q: Does it right solution to compare $l10n_language['short'] while we insert $callback_language_marker into the url?
I have added error_log for both $l10n_language['short'] and $callback_language_marker and they are similar in all my tests in diffirent languages with clean cashe/cookie.
But i can’t realise from the code now, does situation when they are different exist?

imrovement: Looking over class MLPLanguageHandler i have found functions compact_code and get_site_default_lang which are more suitable for shortened default lang determining.
So i reimplemented for my installation that piece of code in such way:

			$default_lang = MLPLanguageHandler::compact_code( MLPLanguageHandler::get_site_default_lang() );
			if ( $callback_language_marker != $default_lang['short'] )
				{
				$result = $l10n_replace_strings['start_rep'].$matches[1].'/'.$callback_language_marker.$extra.$matches[2].$l10n_replace_strings['stop_rep'];
				}
			else
				{
				$result = $l10n_replace_strings['start_rep'].$matches[1].$extra.$matches[2].$l10n_replace_strings['stop_rep'];
				}

However, i have noticed that after applying either your patch, or mine, accessing MLP enabled site with http://localhost/ url while my browser language is similar to site’s default one (f.e. both are uk), MLP-plugin generates redirect to http://localhost/uk/, meanwhile all urls on the page are relative from http://localhost/ not http://localhost/uk/ as expacted.

I have looked over code and guess function _l10n_process_url should be fixed too for default site lang url feature. Later i will post my solution.

P.S.: Please, Bloke, can you add at your repo a kind of a pre-commit hook to regenerate plugins/l10n_version.revision.txt every time plugins/sources/l10n.php changed?
You can point me at the command, that generates .txt file with base64 coded content from .php and i’ll write this hook for you.
Regenerating txt is necessary for serving current plugin txt file in repo

Last edited by adriano32 (2013-01-21 01:11:18)

Bloke · 2013-01-21 01:04:31

adriano32 wrote:

Does it right solution to compare $l10n_language['short'] while we insert $callback_language_marker into the url?

Ah, maybe not. I should probably amend that, thanks. I’ll also take a look at the compact_code improvement when I get a moment and roll it in.

Can you add at your repo a kind of a pre-commit hook

Errr, probably. Never done it: I’ve only just started using git/github. Let me look into it.

Regarding generation of the .txt file, the process is kinda like this. Although I tend to use Plugin Composer for it rather than the standalone generator, they do pretty much the same job when it comes to exporting redistributable plugin.code.

Last edited by Bloke (2013-01-21 01:08:27)

adriano32 · 2013-01-21 01:13:37

I’ve edited post after you answered.

Also i have noticed that after applying either your patch, or mine, accessing MLP enabled site with http://localhost/ url while my browser language is similar to site’s default one (f.e. both are uk), MLP-plugin generates redirect to http://localhost/uk/, meanwhile all urls on the page are relative from http://localhost/ not http://localhost/uk/ as expacted.

I have looked over code and guess function _l10n_process_url should be fixed too for default site lang url feature. Later i will post my solution.

jstubbs · 2013-01-21 01:31:26

OK – I’m using 4.5.2 on this site as I downgraded once I noticed problems with MLP only after upgrade to 4.5.4 and the latest MLP.

As I recently moved this site from Joyent to the new TextDrive, I checked the DB settings. It does indeed appear to suggest that InnoDB is being used as the default storage engine on TXD as opposed to MyISAM on Joyent. So, I downloaded the master branch from MLP and replaced all the files and the two plugins.

But – no joy! The article is saved as in any changes are shown upon subsequent reloading of the article, but not on the public side.

jstubbs · 2013-01-21 01:37:11

Sent you a mail Stef with login details. Might help.

Bloke · 2013-01-21 01:45:35

jstubbs wrote:

It does indeed appear to suggest that InnoDB is being used as the default storage engine

OK, worth knowing — epecially if that’s across the board with TextDrive. Thanks for checking it out.

The article is saved as in any changes are shown upon subsequent reloading of the article, but not on the public side.

Ughhhh, how can that be??!? OK, so first of all: I assume this means that the “Sorry the form cannot be submitted” error has gone away, and / or the spinner disappears when the save completes on the admin side? If so, that’s great. One thing down.

If the article is saved then it has to show up on the public side as long as:

a) The language and article in the URL matches the article you saved.
b) There’s no cache involved.

So after you save, please check in phpMyAdin that the new info is actually there in the right article against the right language and that the “subsequent reloading” of the admin side isn’t pulling in a cached copy of what you just submitted. If the data is there in the DB, then the problem truly is on the public side. Otherwise, there might still be a problem with the save itself. That’ll narrow down where I need to look.

There’s a slim possibility that the bug adriano32 just highlighted is retrieving the wrong URL for the default language. To prove it’s not that, you can go back to the official “MLP 4.5.2” version of the l10n plugin but leave all the files in the lib folder as their “master branch” versions.

I’d ordinarily suspect a cache issue, but I know you’re the kind of guy who checks for that stuff so I’m at a bit of a loss. Thanks in advance for the login: I’ll take a gander when it arrives.

Last edited by Bloke (2013-01-21 01:47:56)

jstubbs · 2013-01-21 01:55:39

Here we go:

1. Edit an english article, then save. The change is shown on screen in the Write tab
2. Clear the cache and refresh the public side. No change!
3. Check the DB for the article, no change!

If there are no substantial changes in the way that MLP works in your new version, then it must be a server issue i.e something like the InnoDB you mentioned…

adriano32 · 2013-01-21 01:58:05

I have dealed with function _l10n_process_url and avoiding redirect for default site language main page when patch for trimming short language code while accessing site in default language applyed.

So, f.e. if both my browser language and default site language is uk and i request http://localhost/ url i will be redirected to http://localhost/uk/ while all urls on the page are http://localhost/ relative.
As i want to avoid such redirect if my browser language are identical to site’s default and stay at http://localhost/ instead of being redirected to http://localhost/uk/, i’ve added in l10n.php at line 327 following code:

		if( $debug ) echo br , "L10N MLP: No language match found, setting to site default ... $long as $short";
		}
+++	$default_lang = MLPLanguageHandler::compact_code( MLPLanguageHandler::get_site_default_lang() );
+++	if ( $redirect and $_SESSION[$ssname] == $default_lang['short'] ) $redirect = false;
	if( $redirect )
		{

we again retrieve default site language and compare it with _SESSION[$ssname] which should be filled by code above based on http_accept_language or some else.

I have applied it already at my site, it works for me.

Last edited by adriano32 (2013-01-21 02:00:06)

Bloke · 2013-01-21 01:59:51

jstubbs wrote:

Check the DB for the article, no change!

Ah, so maybe the save isn’t actually happening. That makes more sense given the effects you’re seeing. Must be some other place in the code where it’s tripping up, as you say, probably because of an unexpected server configuration that needs catering for in MLP.

Bloke · 2013-01-21 02:06:06

adriano32 wrote:

I have dealed with function _l10n_process_url

OK, I’ll do the same in my copy and test it then commit the changes (probably tomorrow when I’m a bit fresher of mind).

Thanks for making this work: it’s a nice feature.

adriano32 · 2013-01-21 02:07:36

jstubbs wrote:

Here we go:

I would have checked first if txplib_db.php file replaced with the one from MLP distribution and then turn on logging of mysql requests.

Last edited by adriano32 (2013-01-21 02:09:08)

Textpattern CMS

Textpattern CMS support forum

#2137 2013-01-20 22:33:50

Re: MLP - The Multi-Lingual Publishing Pack

#2138 2013-01-21 00:43:24

Re: MLP - The Multi-Lingual Publishing Pack

#2139 2013-01-21 01:04:31

Re: MLP - The Multi-Lingual Publishing Pack

#2140 2013-01-21 01:13:37

Re: MLP - The Multi-Lingual Publishing Pack

#2141 2013-01-21 01:31:26

Re: MLP - The Multi-Lingual Publishing Pack

#2142 2013-01-21 01:37:11

Re: MLP - The Multi-Lingual Publishing Pack

#2143 2013-01-21 01:45:35

Re: MLP - The Multi-Lingual Publishing Pack

#2144 2013-01-21 01:55:39

Re: MLP - The Multi-Lingual Publishing Pack

#2145 2013-01-21 01:58:05

Re: MLP - The Multi-Lingual Publishing Pack

#2146 2013-01-21 01:59:51

Re: MLP - The Multi-Lingual Publishing Pack

#2147 2013-01-21 02:06:06

Re: MLP - The Multi-Lingual Publishing Pack

#2148 2013-01-21 02:07:36

Re: MLP - The Multi-Lingual Publishing Pack

Board footer