First of all, I’d like to thank Toño Calo for the new Galician translation. Polylang is now available in 38 languages.
My tests are generally done on a multisite installation with Polylang activated per site. I don’t see the point of network activating a plugin such as Polylang in a multisite installation (i.e forcing all sites of the network to be multilingual), but a few users are doing so and my aim is to make Polylang compatible with this use case too.
Thus, following a bug reported in the support forum, I recently network activated Polylang on my usual local test install and noticed that this action broke the rewrite rules of all sites of the network (except the main one)! I noticed the same issue at network de-activation… I had to dive into the WordPress core code to understand what happens.
A best practice is that plugins manipulating rewrite rules (as Polylang does) flush the rewrite rules at plugin activation and de-activation so that the website works correctly both when the plugin is activated or de-activated. If the plugin is network installed, then this *should* be done on all sites of the network. The problem is that in the current state of WordPress (4.2), the rewrite rules array is not cleaned when programmatically switching to a different site, thus creating a big mess in the rewrite rules of all sites. I opened a new ticket for this issue.
Thus, starting from this version, Polylang will stop flushing rules at network activation and de-activation to fix this annoying bug. It means that in this case, you will need to flush the rewrite rules manually on all sites (by visiting the Settings->Permalinks page).
Nevertheless, based on this experience, I would advise to avoid network activating plugins which manipulate rewrite rules. For programmers reading this, it means that we must not play with flush_rewrite_rules and switch_to_blog in the same time.
Polylang is going on its way to a better stability and the list of other fixes is available in the changelog.
Polylang 
Hi Frédéric, nice to have met at WordCamp!
I’ve got somme ideas about how to make Polylang ‘friendlier’ on Network wide activation but instead of bothering you with a stream of what-if suggestions, I’ll be diving into the code first and if at all possible build a small plugin extension first.
Will let you know soon 🙂
Hi Rolf!
Yes it was really nice to meet you. That would be really great if you have a solution to share. The main issue, where I don’t see how it can be handled by the plugin, is the de-activation.
Sadly, I’ve NO solution for the multisite permalink issue on deactivation.
On activation, yes, there are certain scenarios possible like a plugin DB version compare, triggering a flush on missing or mismatch. I’ve encountered the same thing with my XML Sitemap plugin which is actually designed to be activated network wide. And even then, flushing doesn’t always work and I’ve now resorted to simply deleting the the permalinks DB entry. This (at least in theory) forces the permalinks to be recreated on the next request from either a visitor or an admin, that doesn’t matter.
But even with this method, looping through each site in the network on network-wide (de)activation to remove the permalinks DB entry does not scale at all. Even with minimal processing time per loop, on very large networks this will run into a timeout.
There is an old plugin from Scribu which demonstrates the possibility of a network activation / de-activation which scales. This should work well as long as you don’t have to flush rewrite rules. My problem is that ‘switch_to_blog’ and ‘flush_rewrite_rules’ can’t work together.
Currently, my thinking is that we should create a child class of WP_Rewrite to be used in activation / de-activation process. This would allow to rewrite the ‘rewrite_rules’ method and avoid mixing rewrite rules across blogs. Maybe there are other thing to do. I don’t plan to do this very soon.
My solution is `switch_to_blog` and `delete_option(‘rewrite_rules’)` which as far as I can tell does work together. You can see it on http://plugins.svn.wordpress.org/xml-sitemap-feed/trunk/uninstall.php (note that I leave it to super admin setting a global constant to run network-wide uninstallation; I considered `!wp is large network()` but I’m pretty sure the 10k sites limit is way too high…)
Combining this with Scribu’s Proper Network Activation might be just the ticket 🙂
`delete_option(‘rewrite_rules’)` seems to do the trick 🙂 I just put it in the development version of Polylang. It does even seem to fix #20171. I will wait for more available time to implement the proper network activation from Scribu. At least, the rewrite rules bug is properly fixed now. Thanks!
Hello!
I have a big issue when using Polylang 1.7.8 in a multisite network environment.
If I go to a subpage, I land in an endless loop. It’s switching back and forth between the main page and the subpage.
It has clearly something to do with Polylang (if i disable it, everything is OK) and with the flush rewrite rules.
Can you please help?
What is a possibility to achieve a working network? Installing the plugin on every subpage separately?
Thanks in advance
David
Hi David, installing the plugin on a multisite is a one-time operation but it is currently best to activate it per site. So do not Network Activating it but go into each site’s Plugins admin page manually and activate Polylang from there.
If you really want to activate the plugin Network wide, then after doing so be sure to go to each site’s Settings > Permalink admin page (avoid visiting the front end, use the Dasboard links on the Network > Sites admin page) and re-save the Permalink settings there. No need to change anything, just hit the Save button.
Then create a new site in the network and see if that one suffers the same Permalink problem as the others did. If so, you’ll need to do the Permalink resaving dance again for each new site. And please share you experiences ☺
Hello Ravan, thanks for your answer.
Unfortunately the same problems have arisen.
I now habe found a solution:
– Activate it network wide again
– Put define(“PLL_CACHE_HOME_URL”,false); inside wp-config.php
Now everything works and no endless loops anymore.
That should not be needed anymore since 1.7.8 (thanks to you!)
Pingback: Polylang 1.7.8 | Polylang