Invision Community 4: SEO, prepare for v5 and dormant account notifications By Matt Monday at 02:04 PM
Flitterkill Posted July 16, 2016 Posted July 16, 2016 How do we alert IPS support/devs that there is either a client installation problem that needs actual support or a problem with the IPS core itself when a plugin is involved without getting into a forever circular dance between the support desk tossing things out due to the word "plugin" and plugin authors unable to get traction in the bug tracker as it is un-replicatable on stock installs? I'm on my second right now. The first can get bent, regardless that there is something going on, as he/she has some pirated junk on his install. The second is puzzling, nothing to do with my work, but if escalated to support will get the usual heave ho. I'll throw out the case here, you decide. Kitchen Sink, doesn't install, etc etc. Get acp access, take a look around. PHP script limit 30 seconds, more than 15 other plugins, errors in system log but nothing game breaking. Give it a few tries, all fail for me as well. Naturally on stock installs KS installs fine so... His theme is effectively stock too so that's out of the question, and besides this is just installation not actually using it. So, I take it all apart. I create separate plugins each containing a portion of KS. One holding just the hooks, another just the css, another just the settings, and so on. Hooks, css, settings, js, everything flies through and installs in a heartbeat. The language file does not. I've got 110 plus entries there. So off I go. 10 at a time. 10, 20, 30, 40, 50, 60, 70. All good. Get to 80 and now it starts to time out. Look at the language file that installs perfectly fine everywhere and there is zilch that could be crashing things. Ask and eventually get a bump on php script time to 60. I can get past 80 now but it is substantially slower at this point and I still can't get the full 110+ bits to install. So that's the problem. What's the cause? It's not the php script time on it's face. He has enough memory to handle this according to settings. He has three languages installed, 14000+ language bits in the db. Is there something that is just super inefficient with plugin language installation when there are multiple languages installed? A simple db error somewhere in the lang file? A server configuration that is essential but not discussed anywhere? Somehow there is a size limit on the language file? Maybe a parser conflict with one of his installed languages? And on and on... So, I'm stuck but I can mostly walk away as it is clearly not "me" in the specific sense. He's stuck as there is a problem with something in his system but the moment he goes to the Client Area he'll get tossed as it is "plugin related". I or he throws this at the bug tracker and it comes back as non-replicable. Does anyone have a solution to this?
Martin A. Posted July 17, 2016 Posted July 17, 2016 Interesting. The application installer is taking execution timeout into consideration when importing it, whereas the plugin installer is just doing it all at once, regardless of how many there might be. One other thing I notice in the plugin installer is that an update query is ran straight away when a lang key already exists. The application upgrader does not do this. In your case you're looking at 80-90-100-110 update queries, as the lang keys are already present due to the unsuccessful installations. Looks like there's room for improvement there.
Flitterkill Posted July 17, 2016 Author Posted July 17, 2016 Of course, the latter doesn't account for the initial failed installation but that could be nearly anything triggering that (including the 30 second script time coupled with a somewhat large language db) Didn't feel like querying for latent lang keys but I suppose I should check if they are there. The failed install generally leaves the plugin "installed" enough where you can see it in the plugin list and uninstall it. No idea how much is there to uninstall, or if the remove function works aside from removing from core.plugins. So, the keys might be left over, or might not. EDIT: None of my language keys are there, problems remain. Also, I was mistaken. Approaching 29,000 lang keys in his file. Seems about right for three languages so I was just way off before.
Flitterkill Posted July 23, 2016 Author Posted July 23, 2016 This is tied in to the existence of a second (or more) language file. Just verified on a server with both a dev and live site installed where the live site had two languages installed and the dev just USA English. KS installed on dev but wouldn't on live. Uninstalled KS on dev, installed UK English, and now KS times out on install. The core problem is plugin installation with two or more languages installed and the plugin has, call it 60 or more, language bits the plugin installer will choke on itself.
Adriano Faria Posted July 23, 2016 Posted July 23, 2016 On 16/07/2016 at 0:40 PM, Flitterkill said: Is there something that is just super inefficient with plugin language installation when there are multiple languages installed? Yes, there is. I had an issue with a plugin install too. It had soemething like 50 or 60 lang bits. It simply doesn't install. I had to make it as an app. ?
Flitterkill Posted July 23, 2016 Author Posted July 23, 2016 I hope that won't be the official Invision response. Plugins are a joy to work with due to their simplicity. To push over to apps just because a plugin has 60+ lang bits and the end user has two or more languages installed... Nah, they wouldn't do that... EDIT: The user I aided with this today took it upon himself to remove the second language from his live site and then tried installing the plugin. Installed fine.
Mark Posted July 24, 2016 Posted July 24, 2016 If you have a certain plugin which doesn't install on any site, we can address that via a bug report. If a certain customer cannot install any plugins on his site, we can address that via a ticket. But if a certain plugin won't install on a certain site... sorry, but you would have to figure out the issue.
Flitterkill Posted July 24, 2016 Author Posted July 24, 2016 Then this is just a brutal outlier. Still, once I had this at the language bits greater than X number being the cause I wish there was a way to raise a flag to indicate there is a problem. Rough having to work the IPS bug myself via unpaid plugin support. So it goes,,, For the record for anyone else gandering this at a later time the bug is actually this: If a user has two or more languages installed, any plugin with more than approximately 60 to 70 language bits will fail the installation.
Flitterkill Posted July 26, 2016 Author Posted July 26, 2016 This has been flagged as fixed now in 4.1.14
Recommended Posts
Archived
This topic is now archived and is closed to further replies.