What I did
Let's say my module was called "some_module". Without disabling from the Modules menu, I renamed that folder and changed the contents, now it's "another_module". I perceive that the site is slowing down, trying to still look for "some_module".
What I've tried and expected
I've tried clearing the cache a few times, expecting Drupal to rebuild it's module list based on what's available. However, I'm not sure how the inner-workings of enabling/disabling modules works, and I don't know if my site is still going slow because of this reason, or for another reason.
What I found in the documentation
I read some of the documentation on Drupal Modules, but it looks like there are some pretty simple functions like module_exists(), but it doesn't describe whether or not it will ever stop looking for "some_module".
My question
So, my question is: have I left behind bloated garbage that is slowing down my Drupal site by not disabling the module before renaming it?
And a bonus question...are any of these documented benchmarks applicable to this situation?
Drupal will keep on looking for that module while there's still an entry for it in the system table. Delete the entry from there, delete any tables that your module created, then clear your caches. It will be as if the module never existed so if you still perceive your site to be slow at that point you know that the old module meta data was not the culprit.
Related
So, I have a couple Magento sites (1.9.2+) and recently, styles started breaking frequently. By styles breaking I mean home is displayed as only text. All css, js and images are not found.
I know how to fix this. I just clear cache removing var/cache and everything is fine again.
My question is... why does this happen periodically and now, more often? I've even setup a cron to delete the cache folder hourly. However, I'm still getting this error.
It's really annoying, and hard to explain to our clients when it's happening daily. "oh, just another cache issue", isn't an acceptable answer for me.
All answers I found so far just fix it once, and never mention it happens periodically.
Any ideas as to prevent this from happening?
Thanks!
I would not set up a cron to clear the cache. So remove that asap. What 3rd party apps have you installed around the time your had these issues. My guess is there must be a process / action that is periodically occurring that causes this change. Check your error logs and exceptions also /magentoroot/var/logs
Last possible reason (although rather slim chance) is you have a sitewide ssl setup but its only valid for certain urls.
This has been extremely frustrating. I installed a module Finder in Drupal installation. I was tweaking some settings in it and then after changing some settings it started showing off some Ajax errors and then there was the White Screen, showing this error:
Fatal error: Call to undefined function views_include() in /var/www/drupal/sites/all/modules/views/includes/plugins.inc on line 9
Using Drush, I disabled the Finder module and cleared the cache. But nothing happened. Then I disabled the Views module. The White Screen was now gone.
And now I am stuck. I had some pretty good work done in this site and when I re-enable the Views, White Screen reappears. It seems to me like the Finder module made some irreversible changes somewhere in Views. I mean how come my Views is not working when I've cleared the cache and Finder is disabled?
Has anybody ever come across such a thing in Drupal? How did you solve it?
UPDATE
I just found that the developer of the "Finder" module is claiming it to be a bug in Views. See here: http://drupal.org/node/1611106. As suggested, commenting out that particular line 9 in plugins.inc of Views module does work. However, I'm still skeptical to accept to be a bug in Views.
It's not Finder; it's either Drush botching an update or perhaps you relocating the module, causing the registry to become out-of-date. Check that views.module actually exists, Views is enabled in the system table and then rebuild the registry as nmc suggested.
That should fix it but, at worst, you can comment out the views_include('base'); call at the top of plugins.inc as a quick hack to recover your site.
I just got this error too. Funny enough it was also while playing around with settings in the finder module. Playing with the ajax settings to be precise.
Anyway, to get your site back when you get the error and white screen, close your browser and reopen it a a page other than your site and clear all the browser cache. You should then be able to see your site again.
It happen to me after setting 'Ajax' to 'yes' under the form heading on the edit finder page.
After you have reopened your browser and cleared the browser cache, go straight to the edit page for the finder that is the culprit and set 'ajax' to 'no'.
Perhaps the Registry Rebuild module may help you.
When would you need Registry Rebuild?
You might get something like:
PHP Fatal error: Class 'EntityAPIControllerExportable' not found in
...sites/all/modules/rules/includes/rules.core.inc on line 11
If this happens when you're trying to run update.php, and happens when
you're trying to clear your cache, well, you have some trouble. That's
what Registry Rebuild is for.
I've never used it myself so I recommend that you look into the code before running it but I hope it helps you.
See
http://randyfay.com/node/105 and
http://drupal.org/project/registry_rebuild
For me, rebuilding the registry with drush rr didn't work. Disabling the module, uninstalling ad reinstalling didn't help also. The only thing which worked was to clear the sessions table.
The issue: a content editor saves a new content item and gets a 404 on the proper-looking url for the new object. If they then refresh, the item is there, perfectly normal.
This happens for multiple Archetypes-based content types, and we've seen it on at least two different sites. We've seen it on Plone 3.x and 4.0.3. Here's what these sites have in common:
HAProxy load balancing (with and without session affinity)
Multiple ZEO clients
Using either ZODB 3.9.7 or 3.8.4
The issue happens only some of the time, maybe for 1 out of 4 content items
Has anyone seen anything like this?
I do not have an answer for you; this should not really happen. I certainly have not seen this.
You'll need to gather more information to troubleshoot this, and that perhaps requires interactive access to experts, and SO is not the place for such troubleshooting.
All I can do is advice that you gather as much information as possible, including a full trail of the user interaction from the various logs, including HAProxy and the ZEO server.
It may require additional instrumentation at the server level (when the NotFound error occurs, dump additional information about what is present, etc).
Some recomendations/questions:
Verfy that the content object was, indeed, created.
Check that the content views are correct (the ones that are declared in profiles/default/types/yourtype.xml).
Does it happen when adding content directly to plone instance (Without caching and load balancing?
Does it happen when adding content to direct plone instance with load balancing, but without caching? ---> And so on ...?
Maybe not an elegant one, but you might try inserting print statements or pdb breakpoints in the code so you can track whenever a content object was, indeed, created. Do this only as a desperate method of "instrumentation".
Yes. we have recently started seeing the same issue. We have almost the same setup. Haproxy (no session affinity).
I'm wondering since the pattern seems to be haproxy... perhaps its an issue with a request being redistributed after a timeout?
Updated:
We had this issue. It happens when you have a redirect back to the changed object after a save. This is because the 2nd request hits another zeo client which doesn't realise it's out of date.
The only solution we found was a to add temporary session affinity in haproxy (20s) during any POST. Not ideal but does work. I was just searching for a better solution which is why I found this old post.
For some reason I can no longer post a comment as an Anonymous user in my Drupal installation. I haven't tried in a while, so I'm not quite sure when this functionality was broken.
I have Services installed, and I can post anonymous comments using comment.save. I have altered the Input Formats if that could break something.
I have enabled both post comments and access comments on the anonymous user. The comments does not show up in the database. In fact, the native Drupal function comment_save isn't called when I try to comment as Anonymous (I check this by adding print_r($edit);die(); at the top of the comment_save function in comment.module. Also I read something that not having a User with the UID 0 would break the Anonymous commenting, this user exists (obviously, since commenting through Services works)
I have tried out the AntiSpam module, and posted a comment as Anonymous that would get caught(and did) in the spamfilter, but this module is now disabled.
I'm really running out of ideas here, does anyone have any other suggestions on what to do? In the meanwhile I'm going to attempt to backtrack the code to figure out why comment_save() isn't being called.
Edit: Anonymous users also don't have to submit email and such to post, if that matters in any way.
By what you say, I suspect the problem is with some contributed code hooking on the comment form and modifying it in a way that makes it fail submission. This can be caused by a number of causes: a jQuery that adds fields to the form without regenerating the form-id on the server, an added or cusomised field that changes the callback to submit the form, etc...
I cannot know it for sure, but here's what I would do if I were you, in order to check what's up with your installation:
Make sure you disinstalled (and not only disabled) the modules you tried and don't use anymore. Modules should never touch core tables, but who knows... It does not cost anything and it actually frees some of your DB.
Try disabling all contrib modules and see if you can comment that way. If this is the case, activate the contrib modules one at a time until you find out which one is the culprit. Chances are you will already find a patch/workaround in the issue queue for that module on http://drupal.org. If you don't find a fix, I would investigate (xdebug or manual tracking) the code, and I would pay special attention to all implementations of hook_form_alter() and hook_form_FORM_ID_alter().
If even disabling all contrib modules doesn't help (which I would be very astonished of), try updating the core with a fresh installation if you consider as a possibility that your cat walked on the keyboard while you had a core file opened, or you live with Gordon Brown's family.
Failing that, the only alternatives coming to my mind are much more esoteric, such DB failure, a greasemonkey script on your browser interfering with commenting and similar unlikely possibilities.
HTH!
I solved this once by resetting the permissions table (http://drupal.org/node/64114), but I would do a proper backup and keep the permissions page open in a tab, just in case.
I have an incredibly frustrating problem cleaning up my site at the moment. On the same hosting space I have Umbraco (ASP.NET) and Blab Lite (PHP Chatroom) installed. The former talks to SQL 2005, and the latter to MySQL 5.
On my Umbraco site I had a guestbook with an entry form. Upon postback it does an Akismet check and skips the creation/saving of the corresponding Umbraco document if it is verified by Akismet as spam.
However, recently I started getting entries created under my guestbook node which are verified as spam, and yet the document is still saved. I have even gone as far as hiding the form using "display:none" and yet these entries are still created! I have modified the DLL to include logging to Umbraco document event logs and somehow the creation of these still does not trigger any entries to the logs. I've even created an eventhandler for Document.BeforeSave event in a separate assembly and this event handler is not catching the saving of these entries.
I'm really stumped as to how the spammers can create these entries. Has anyone got any ideas how this can be done, and how I can secure my site to prevent this kind of attack?
Thanks,
Dany.
This seems like an old post but it's not marked as answered so I'll give it a go. I havnt used Umbraco in a while so I'm not sure if they've fixed this in the latest version, but the problem is with Umbraco it self. Document.BeforeSave() gets fired AFTER the node is created, that's why your spam filter is not working. Marking the form as not visible wont work because the bot will look at the source code and just pattern match the form fields it finds. Have a look here for more details on the Umbraco problem:
http://forum.umbraco.org/yaf_postst9312_BeforePublish-and-BeforeSave-Event-Handlers.aspx
Like I said I haven't used Umbraco in ages, but hopefully it will help someone even if you've found a fix.
Paul
My guess is that there is a bug in your code to skip the creation/saving of the Umbraco document... although it is strange that the Document.BeforeSave event is not triggered. Are you sure that your event listeners are also working (i.e. do they register the saving of non-spam entries?)
By the way, setting "display:none" won't stop spammers as bots will generally ignore CSS anyway.
Yup, the event listeners are working indeed. This lead me to think something else is odd here. I finally took the plunge and went through it all with a finer-toothed comb. First I compared the content of the bin folder between standard Umbraco 4 distribution and the one on my host. I figured it was easiest to overwrite each one with a fresh one. Then I went through each Umbraco package I've installed and made sure the DLLs are also fine. Well, there was 1 DLL that didn't match anything else in Umbraco or packages I've installed - EO.Web.dll!
It seems there's a legit thing out there by EssentialObjects but I don't think Umbraco, my code, or any of the packages actually uses it! I deleted it and every part of my Umbraco install still works! I've now set visibility of of the form in ascx markup so it's not rendered - now we wait and see if that was the offending piece of malware!