config menu and page disappear intermittently.

Same

Same.

FIX: Disable and re-enable the module, the settings page re-appear.

Note: is the module actually non-functional during the time the settings are unavailable? Anecdotal, but I noticed an increase of spam coming in during this time.

7.x-3.2

i had the same issue. botcha dissapeared from my toolbar menu. dispable and re-enable the module fixed the issue. If this happens again and the module becomes non-functional then this is a serious bug that should be resolved.

well it disappeared again!
flashing the caches brought it back.
this shouldn't be happening....

I don't see it in the menu either.

I think it gets lost every time I create a new webform, or edit the webform settings.

Same here with 7.x-3.3!

We don't have webform installed - and yet it disappears regularly...

I can confirm that it has disappeared for me as well. Clearing the cache seemed to fix for now.

It disapears on cron runs (I have elysia cron)
flashing caches in not always working, have to disable and re-enable it
(no settings are lost)
can someone confirm that it is actually working when it disappears ?

Ok I can confirm my own request...
It is working even if it is not visible on the menu...

I have the same issue on 7.x-3.3.

Clearing the cache brought back admin/config/people/botcha

During the time the config page was missing the module continued to function.

D7.23 and botcha 7.x-3.3

Admin page disappears from admin/config/people/botcha

Disabling and re-enabling module brings it back with all config intact

While admin page was missing, my only protected form (a webform 7.x-3.19) was unprotected (I got spam which was not logged as approved)

Changed Status to Needs Work (as per https://drupal.org/node/73179)

I am running the latest Drupal 7 (7.26) and the latest Botcha (7.x-3.3).

Botcha will "cram" itself when update.php is run. When it is "crammed", it will block any submissions to pages it protects and will require a cache-clear to come back online.

Hopefully this can be resolved. BOTCHA appears to be a good anti-spam feature.

Andrew

I was wondering what was going on. After running update.php the botcha config page disappears every time.

"Needs work" status only applicable if there is a patch attached that needs more work.
It is a bug, but which module?
My understanding is that config menu disappearing is happening due to issue(s) in Moopapi module. Prior to Botcha refactoring to use moopapi, Botcha had no such problems.

Update is flushing all caches, but it probably does it differently from "flush caches" which restores config page.

This is confusing.

In my own testing (moopapi 7.x-1.2 and botcha 7.x-3.3):
- Botcha disappears from the menu after running update.php
- Botcha appears again after flushing all caches or running cron.
However some report differently (#10).

Then some report Botcha keeps on working (#11, #12) while others say it doesn't (#13, #14).

This is a strange issue... I spent a little time this morning looking at it.

I updated Entity and Botcha disappeared from the "Configuration -> People" part of my admin menu.

I added a hook to the botcha module to run drupal_flush_all_caches() and cache_clear_all() when the update script is run and return a message letting me know it had run but neither made a difference. Botcha was still missing from my menu. Only when I used the flush all caches from my admin menu, magically, the botcha item reappeared in my admin menu and it again ran correctly.

I'll keep tinkering but I'm certain now that all caches need to be flushed after update runs not during. I'm stumped for the moment. It would be great if we could make a rule to do this but as far as I know, we can't create rules based on after update.php has run.

Edit: It seems to go awry whenever update.php is run, regardless of whether an update runs or not.

I'm having the same issue after running update.php, disable and re-enable the module solved the problem...

I've been disabling Botcha & enabling it again from time to time. But #17 worked for me where it appeared again after flushing cache, so I guess we just gotta remember to flush it each time update.php is run until a permanent solution is found. Thanks for the tip!

Having the same issues on Drupal 7.23 + 7.27 and Botcha 3.3. For me the module keeps working altough it is not displayed on config screen.

Clearing cache works to get the config screen back but this is a bit of a pain on a site with a lot of traffic.

I did some testing with Drupal 7.31 and Botcha 3.3 and found that by clearing just the following caches in this order through the Admin Menu Botcha came back:
1) Class Registry (/admin_menu/flush-cache/registry)
2) Menu (/admin_menu/flush-cache/menu)

I can confirm #22 brings it back for me. I will keeping checking to see if it disappears again.

Just to confirm that this is still happening and can be temporarily fixed by clearing caches

Specifically clearing the "Menu" cache through Admin Menu, resolved the issue (temporarily?)

Confirming that this is still an issue. Clearing all caches temporarily fixed it.

I saw this as well when I was using Botcha. The hook_menu() is not done in the typical way within a module file with hardcoded uri's, rather in the file botcha.application.controller.inc as a public method of the class Botcha (which is actually a subclass of moopapi's "Application" class). This subclass does the integration with moopapi.

I see no reason why hook_menu can't just be moved to .module. For the multiple calls to Botcha::ADMIN_PATH, you can just define that in a constant in .module and use that instead:

<?php
// botcha.module file
define('BOTCHA_ADMIN_PATH', 'admin/config/people/botcha');
function botcha_menu() {
  $items = array();
  // Main configuration page of BOTCHA module.
  $items[BOTCHA_ADMIN_PATH] = array(
  //...
  );
  $items[BOTCHA_ADMIN_PATH . '/general'] = array(
  //...
  );
  // etc.
}

// botcha.application.controller.inc 
class Botcha extends Application implements IBotcha {
  const ADMIN_PATH = BOTCHA_ADMIN_PATH;
  // ...
}
?>

Anyway this is not tested but this may be the reason it does not always get picked up in menu router cache since "hook_menu" is actually not a stand-alone function but a public function inside of the Botcha subclass.

Clearing both class registry and menu did the temporary fix. I've updated the summary to have a quick fix available.

This module requires OOP, which is great in principal but the methodology for providing the hook_menu through the controller.inc file only works intermittently. This is a huge problem for a critical module. I can't be forced to clear cache every time I want to use this module, especially on larger production sites where clearing cache affects the user experience.

added drush example

I was having a similar problem with another module (Panels), but the problem was with Admin Menu. I had to disable Cache menu in client-side browser and then the admin config menues started to work again.

Bye!

I applied the suggestion in #27 and it worked well for me.
Attached is the patch to apply that suggestion to the 7.x-3.x-dev branch of the module.

Patch at #33 works for me. Many thanks.