Modules that have "requires" sometimes disappear #1011
Comments
|
I do have the same problem the second time on a clients website. Both times the "LanguageSupportFields" module disappeared after clicking "Refresh" from the dropdown menu. Each time I had just uploaded a new autoload module beforehand via ftp. The site is maintained by another developer, who has not worked with processwire as much as I have, and it's really not nice to have to ask for the backups again. |
|
@LostKobrakai: Was that just for a single request after uploading the module, or does the error re-appear on every page load after that? While I've not seen that myself, it's not unexpected that wiping the modules cache may cause some autoload modules to not load for one request. But what's odd is that PW does a redirect immediately after so that you don't have to see the stuff that appears in your screenshot. It looks to me like that redirect isn't occurring in your case. Is it possible some autoload module generated some output (even whitespace) that got sent? That would prevent a redirect header from functioning. @somatonic: The LanguageTabs issue was fixed several dev versions back (and I was able to reproduce that one at the time). If you are still seeing the issue, double check that you don't have a copy of language tabs in /site/modules/. If still seeing it, can you tell me what other modules are installed in /site/modules/? As for other modules, the situation you describe can occur when you have an autoload module that has a "requires" for a non-autoload module. That dependency can't be fulfilled, so the autoload module isn't able to load at all. Would this be the case with the login history module you are talking about? |
|
It's persistent, but could a hook to LazyCron cause this, when lazycron is not installed? Edit: the module was installed before the refresh, too. Noticed the missing LazyCron only now after reading your post. |
|
I don't think LazyCron should matter. Hooks to modules that never run are simply ignored. What other modules are installed in /site/modules/? |
|
Do you see that "Array Array Array" that appears in your nav on every page load in the admin? Just wondering what that is. Seems like something is very amiss in that screenshot. :) |
|
|
|
By now I always thought, that the Array stuff does appear, because the multilanguage module got lost. |
|
What are the dependencies for those language-related modules: ProcessLanguageTranslatorPlus and LanguageInstantInstall? Are either autoload? I need to setup something that lets us temporary disable autoload modules on an individual basis so that we can more easily debug this kind of stuff... I think that's what I'll work on now. |
|
Just had a look at the backend few aren't even installed. Modesta |
|
Just got a replay from the dev maintaining the site. He said changing one line in the database fixed it again. Dumps here: https://www.dropbox.com/sh/8hzc5t6cg7etjso/AAA1iETXNaOWpuKlRjdZ_-Hfa?dl=0 Why can't I upload textfiles here… |
|
I can't seem to access that link. Can you describe what database change fixed it? |
|
Just managed to get a usefull diff out of these files. |
|
I'm reading from a cellphone here so might be missing something, but looks like the cached lines for LanguageTabs and LanguageSupportFields were removed, and a line for FormBuilderFileDownload was added? I would think those two Language module lines got added right back after a modules refresh. Though if it's working now, it would be interesting to know what's different (if anything) between how the entries are for those modules (184 and 180) now versus what's here in that diff. |
|
The diff is maybe confusing as it's actually inverse. If I got that right, then the 2 language rows didn't get added back to the cache and instead the FormBuilderFileDownload was in the cache. After adding the language modules back in and removing the FormBuilderFileDownload it worked again. One thing I notices I had this |
|
Its still quite a mystery. How did you know what lines to add to the
|
|
As I had created this error the second time I emailed Markus ( the other dev) to look for the database backups and this where the only differences before and after the refresh from the database side. I just created the install locally and can't even get it to behave like this. |
|
I think this is related to: #905 |
|
Yeah it does sound like the same issue. I sure wish I could find a way to reproduce this one. There seems to be something there, but I've yet to see it occur myself. #905 seemed to have some talk of ModulesManager. @LostKobrakai does the installation where you saw the error have ModulesManager? I can't imagine it would matter, but I don't have a way to debug this yet. |
|
Jep, ModulesManager is installed there. |
|
if i recall correctly, both times i was using modules manager; once i was updating procache from v1 to v2 and it knocked out the reno |
|
In my case I lost one of my modules (Pages2Pdf) and I don't have ModulesManager installed. It happened after installing another module (manually copied module files, then installed via the admin). |
|
Also have had these problems without ModulesManager. Never really understood which causes these problems and how to reproduce, so far they feel totally random. Only hunch is that there is always "requires", "installs" etc. dependencies in play. |
|
I just got my local "debug" installation of the site to not show my own module. Maybe I can now help out with information. |
|
Thanks, good to hear, I'll think of more things to try if the latest update doesn't fix it. I've gone through and basically revisited all the parts involved and recoded some parts (in wire/core/Modules.php). But I'm flying blind with regard to this particular issue, since I'm not seeing it here. So just shooting in the dark, hoping I might nail the issue one way or another. Hopefully I didn't break anything. Would you mind giving it a try? Once installed, you'll want to do a Modules > Refresh and click around to another page, then check to see if your module is still gone. Thanks. |
|
The update didn't solve it. The module is still gone. |
|
I just noticed, that every few seconds this gets logged: |
|
For the module that's gone, what does it state in its getModuleInfo() for the 'requires' property? Is the moduleInfo provided via a getModuleInfo() method or a info.json or info.php file? |
<?php
class FormBuilderFileDownload extends WireData implements Module, ConfigurableModule {
public static function getModuleInfo() {
return array(
'title' => 'Form Builder File Download',
'version' => 2,
'summary' => 'Extentions for Form Builder, developed for Made Projects',
'singular' => true,
'autoload' => true,
'requires' => array("FormBuilder", "LazyCron")
);
}
… |
|
Those two modules installed or uninstalled? I'm going to try and duplicate 'Form Builder File Download', 'version' => 2, 'summary' => 'Extentions for Form Builder, developed for Made Projects', 'singular' => true, 'autoload' => true, 'requires' => array("FormBuilder", "LazyCron") ); } — Reply to this email directly or view it on GitHub https://github.com//issues/1011#issuecomment-78525052 . |
|
FormBuilder is installed and LazyCron is not. |
|
I just tried to duplicate it but didn't have any luck. Here's the test module I used. I started with FormBuilder installed and LazyCron uninstalled. When I did a modules > refresh, it showed up on the "New" tab but wasn't installable, stating it "requires LazyCron". I installed LazyCron, then installed the module. Is my test module above missing any key parts you can think of that might help to reproduce the issue? Where is the location of the module file on your file system? Mine was /site/modules/FormBuilderFileDownload.module |
|
The path is this: |
|
I got it to disappear on a fresh installation by having only FormBuilder installed. Then I installed FormBuilderFileDownload with the typo |
|
Was the module visible to PW when it had the typo? Are you sure the module On Thu, Mar 12, 2015 at 1:37 PM, Benjamin Milde notifications@github.com
|
|
Jep, otherwise I couldn't have installed it (easily…). Chmod is |
|
I tried what you mentioned about taking that module, giving it a typo for 'required' and refresh, then move it out somewhere else, refresh, then move it back in and fix the typo, refresh, but still not able to reproduce it. I tried it on 2 installations, one blank, and one with a lot of stuff in it (including FormBuilder). Somehow ProcessWire can't see the file, but it's still a large mystery as to why. It sounds like you were looking at those cache tables before. The FormBuilderFileDownload should appear in the ModulesUninstalled cache. That's where PW keeps track of modules that it found on the file system, but not yet installed. |
|
i can confirm that the disappearing Reno happens on sites without formbuilder; |
|
Did you install it with the typo already in place? I think that's the key, moving the folder of the installed module away. Then hitting refresh should notice the missing module and remove it's database entry. But if it's dragged back with the typo fixed it errors because of the missing required lazycron (log entry) and because ProcessWire seems to still have it listed as "installed" (caches db, but could also be only the refresh after adding it back). It's just not listed in any way in modules section of the backend. |
|
I didn't install the module with the typo in place before. Just started over with the blank profile, installed it with the typo in place, moved it out, refresh, fixed typo, moved it back in, refresh. Then I get the error message:
But that's the correct error message. Basically, PW doesn't know the scope of that dependency so it's not taking risks. It might be a class-extending dependency for all it knows. So it prefers not to touch the file at that point (one of the reasons PW now supports separate info.json/info.php files). If it did, you might then have a fatal error from PHP that PW could not catch (as would be the case with a class extending dependency). So at that point you'd have to meet the dependencies in order to get the module back on your screen. It can't show you the module in your modules list because there's nothing you can do with it. You can't safely uninstall the module because it would have to instantiate the module file to do so (to call its uninstall method). The only ways around this are to meet the dependency or remove the file. |
|
Hi, I just wanted to add (as another datapoint) that AdminThemeReno disappeared when I detected the Procache module. Reported it in the Procache support forum and was guided to this threaded. I was using PW dev 2.5.21 and Procache latest (2.01). |
|
I was thinking the issue with FormBuilderFileDownload was likely the same thing as what some have seen with AdminThemeReno and LanguageTabs. But now thinking it's something different, because the disappearance of the module in the scenario described above makes sense. But the disappearance of LanguageTabs or AdminThemeReno still doesn't make sense. So I'm still keeping my fingers crossed that today's updates may have fixed that issue. If anyone sees the issue still turn up with AdminThemeReno or LanguageTabs after the latest updates, please let me know. Or if you were seeing it before and now no longer seeing it, would be interested in that too. :) In either case, one won't be able to tell until doing a Modules > Refresh once or twice though. |
|
PS: I just tried uploading Procache on a fresh install (2.5.22 dev) and AdminThemeReno was fine. |
|
That's a good sign! Thanks for testing. |
|
Hopefully I recreated the same error as on the real page. I'll check the logs. But this error should really be more prominent. I found the errormessage, that you got, too, just because I've actively looked into the log files, but I never got the error message via the system notifcations. |
|
If you've got debug mode on, you should see it in a red banner across the top of every admin page. But it's not a fatal error (or even a problem to normal operation), so probably not something you want every person in the admin seeing on every page. I know it can be a concern having debug mode on production sites. You might want to enable the $config->debugIf option so that debug mode shows for you, but not for other users on the site. Thank you for the testing help today. Even though it may have turned out to be a different issue than the original, I think it helped greatly in [hopefully] solving the AdminThemeReno/LanguageTabs/etc. module issue. Though it remains to be seen whether that issue is really fixed... but as much code as I rewrote today, I'm holding out some hope that it is. :) |
|
https://processwire.com/talk/topic/9362-strange-language-problem-after-installing-module/ |
… where the issue was occurring, and so finally I was able to see it in action, and that made it easy to pinpoint and fix the issue (at least the one that was occurring in this particular site profile). If anyone else has experienced the issue, please give this commit a try to see if it also fixes it for you. Thanks.
|
For me it seems to be fixed with 84be3e4 |
|
Good to hear, thanks! On Fri, Mar 13, 2015 at 8:02 AM, Christoph Roeder notifications@github.com
|
|
Finally! Let's hope! 💃 |
|
I think that this could be related? Not sure. I had the HannaCodeHelper installed and working for a while. This morning, without having seen an error note before, the module was de-installed and even disappeared from the list of installable modules (its files are still existent within the site/modules folder). |
See this thread that is currently a problem with language profile and issue with LanguageSupportTabs
https://processwire.com/talk/topic/8646-problem-with-module-languagetabs-dependecy/
I have same issues in other installs with ProcessLoginHistoryHooks that also has a "requires" dependency.
https://processwire.com/talk/topic/2082-module-process-login-history/?p=88573
Seems like somethings broken with the module dependencies that should be tracked ASAP, as it makes it unpredictable that module just dissapear.
The text was updated successfully, but these errors were encountered: