在禁用模块之前删除了模块的文件夹
我做了什么
假设我的模块名为“some_module”。在不从“模块”菜单中禁用的情况下，我重命名了该文件夹并更改了内容，现在它是“another_module”。我发现该网站正在变慢，仍然试图寻找“some_module”。
我的尝试和预期
我尝试清除缓存几次，期望 Drupal 根据可用内容重建其模块列表。但是，我不确定启用/禁用模块的内部工作原理，并且我不知道我的网站是否仍然因为这个原因或其他原因而变慢。
我在文档中找到的内容
我阅读了一些有关 Drupal 模块的文档，但看起来有一些非常简单的函数，例如 module_exists()，但它没有描述它是否会停止寻找“some_module”。
我的问题
所以，我的问题是：我是否在重命名模块之前留下了臃肿的垃圾，这些垃圾会减慢我的 Drupal 站点的速度？
还有一个额外的问题......这些记录的基准是否适用于这种情况？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当
system表中仍有该模块的条目时，Drupal 将继续查找该模块。从那里删除条目，删除模块创建的所有表，然后清除缓存。就好像该模块从未存在过一样，因此如果您仍然认为您的网站此时速度很慢，您就知道旧模块元数据不是罪魁祸首。Drupal will keep on looking for that module while there's still an entry for it in the
systemtable. 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.