"This page has no Process assigned." with lastest dev and some modules

[maba]

Hi,

with the latest PW dev I've some problems with modules.

Go to /setup/MODULE and:

This page has no Process assigned.

This happens with "Export Site Profile" and "Modules Manager" for example. Not for all modules.

Uninstall and reinstall operations does not fix the problem.

Any idea?

Thanks,

Marco

EDIT: best answer for the first problem mentioned in post title.. other posts refers to a very strange problem on my installation.

Edited November 28, 2013 by maba

[adrian]

Have you tried deleting all the module related items in the site/assets/cache folder?

[maba]

Yes.. This happens on two different under dev sites.

Cache removed after uninstall and new installation. 

Another strange behavior.. after new installation I cannot see the new item under setup menu, but module is saved in module table.

[adrian]

I have had similar issues in the past, but not for a while. I am running 2.3.7 - from a few days ago. Have you also tried manually deleting the row from the modules DB table, or is the uninstall still working properly and taking care of this?

Other than that not sure - sorry!

[maba]

For the first site I manually deleted the row and it was created by the installer again, but not the child under setup.

For the second site (cleaner situation) uninstaller/installer works well, child menu was not deleted.

[Wanze]

You can open the page under /admin/ (in your site tree) and check if there's a Process selected, or add the right one if the field is empty.

[maba]

Ok.. for the second site it works.

This morning I tried on first site with no luck.

Now on the second site and It works. But why the new installation does not work in the right way?

On the first site.. no. Now /setup/moduelsmanager go on timeout with no logs, with ModulesManager. Strange behavior, same MAMP machine.

And why it does not create the correct child on setup?

Thanks

Edited November 21, 2013 by maba

[maba]

After some tests I not found a solution but site 1 works with modules manager limit < 100 (350 on the other site).

Same dev machine.

[ryan]

What Wanze mentioned is the way to fix it. It sounds like the page just lost connection the Process, which can be easily fixed by editing the page and selecting the right Process for it. This can happen of you use the site profile exporter and don't include the 3rd party module files in your profile (that's the only way I've seen it happen), though maybe there are other ways it can occur too.  It also sounds to me like you may need to increase the memory available to PHP. If a limit of 100 modules in ModulesManager works, but 350 doesn't, then it sounds like you are running out of memory. I usually give my PHP installs 128m or 258m for memory (depending on how big of images it needs to deal with). 

[maba]

Hi Ryan, yes give the right process fix the "first" problem but it happens only after the PW update. In this case I didn't use export profile. 

Strange because both sites runs on the same MAMP machine with 128Mb for memory. And.. early no site given this problem, with limit set to 300.

Today I'll test these sites on another MAMP installation and 256Mb for memory on the first dev machine.

Thanks

[maba]

Nothing.. 256Mb on new computer and same problem.

[martind]

hi,

i have a similar case here on a fresh install of 2.3.7 with somas modulesmanager. After installing the module errors with not read of .cache file, there is another thread about it. After setting all permission, removing cache files and re-installing mm, setup>modulesmanager quits with "This page has no Process assigned."

After assigning the process, setup>mm launches in "cannot read cache file.. /site/assets/cache/ModuleManager.cache", the files get written in cache dir, ModuleManager.cache with 0bytes. Setting it manually to 777 doesn`t show any effect.

greetings, martin

[Soma]

I'm not sure what about the cache file of ModulesManager. It only checks for assets and modules folder to be writeable, but cache should already be writeable.

After all the cache folder gets created by PW (php) when installing. So only thing I can imagine is some permission issue on your server. Maybe you have created or uploaded the folder with ftp and it conflicts with php owner rights. Hard to say but all possible.

For the missing process:

Looking again at the ModulesManager install, uninstall methods, there's definately a bug when uninstalling the module (never done that really ) The setup/modulesmanager admin page won't get deleted but should. After installing it again it finds the still existing admin page and doesn't assign a process of course.

Thanks for mentioning, I will fix this later.

[maba]

@soma thanks for the check on install/uninstall methods.

About the cache "problem": I can exclude any permission related issue for my installations. Tested on two different dev computer, MAMP, etc... 

In my case the two ModulesManager.cache files are both 283Kb and are generated in the right way.

One installation can use 350 limit (found 210 modules), other can use only 100 limit.

I'll try to remove all other modules and check it again.

[Soma]

I have a hard time to understand what you saying with all the problem you got. Updating PW (means replacing /wire/ folder only) does nothing you mentioned like loosing processes for admin pages or problems with ModulesManager.

Now that we are on ModulesManager. As Ryan says I'm not sure what the problem is for your install, but looks a lot like a memory or max execution time for scripts, which is a php setting. I never experienced any issues like you mention so I can't really see what's happening. Surely removing other modules in this case wouldn't help or do anything related to that particular issue with ModulesManager.

[maba]

Hard time also for my english probably.

Problems beginning with a PW update. ModulesManager was the first module affected (and after Export Profile). I think that I can exclude any related memory or permission issues.

Site works well but in admin I have all these problems. 

Says about to remove all other modules only for test.. (Modules Manager compares installed and available version of a module, maybe..)

At least.. we catch a little bug in ModulesManager.

[Soma]

No problem maba, we are all only humans.

As said, simply updating PW wouldn't do anything what you mention. I've run so many updates and rollbacks of PW and never experienced anything like that. It would be also good to know what you did update, from what to what version. Also sometimes not sure what you mean with updating, or installing as you don't tell "what".

The bug in ModulesManager only ever happened if you uninstall MM and reinstall it.

[martind]

thanks soma, for your reply.

I also thought about permission-problems between ftp-user and apache. I think this concerns all webhost-packages on world4you.com, at least with pw 2.3.7, have tried modulesmanager on another clients site and it was the same problem. I can give you a phpinfo if you are further interested in this problem. For me I will check off w4y-hosts as not modulesmanager compatible, we also had php related problems on webspaces of this provider in the past. except for this pw runs ok, there isn`t much need of addon-modules.

thanks

martin

[maba]

Guys, this is the line in MM that generates the problem (ModulesManager.module):

$actions = $this->getActions($module, $uninstallable, 'download', $theme);

Comment this and the site works well.

What's wrong with this call?

$button = $this->modules->get('InputfieldMarkup');

Edited November 26, 2013 by maba

[Soma]

thanks soma, for your reply.

I also thought about permission-problems between ftp-user and apache. I think this concerns all webhost-packages on world4you.com, at least with pw 2.3.7, have tried modulesmanager on another clients site and it was the same problem. I can give you a phpinfo if you are further interested in this problem. For me I will check off w4y-hosts as not modulesmanager compatible, we also had php related problems on webspaces of this provider in the past. except for this pw runs ok, there isn`t much need of addon-modules.

thanks

martin

I don't think phpinfo will help with permission problems if there's any, but then I'm not sure anymore what problems you currently have with PW or ModulesManager... Generally it's usually a permission problem when writing or reading files fails, and it's not something I can do anything about, at least I'm not aware of and most of the problems with php setting is already covered by the MM module to throw an descriptive error. I'm no guru when it comes to permissions and what all can go wrong on all those hostings and combinations of settings.

Guys, this is the line in MM that generates the problem (ModulesManager.module):

$actions = $this->getActions($module, $uninstallable, 'download', $theme);

Comment this and the site works well.

What's wrong with this call?

$button = $this->modules->get('InputfieldMarkup');

Huh? What problem? Any more infos? Errors? 

I don't think there's any problems with any of the above, nothing wrong here, not something I can say Ahhhh....

I think you have other problem with you general PW install, like some missing files if the $this->modules->get('InputfieldMarkup'); has a problem cause there's nothing wrong with it.

[maba]

It happens only with

$action == 'download'

no messages or warning. 

It fails from the first call (InputfieldAceEditor).

"Test" is a placeholder for all modules that require "download" actions..

Other actions works well.

[Soma]

Can you enable debug mode in site/config.php and see if there's any error/warnings? Or if nothing in PW error log or apache error log?

If you said $button = $this->modules->get('InputfieldMarkup'); is the problem, which shouldn't at all, can you look if the InputfieldMarkup.module exists in you /wire/modules/Inputfield/ ?

Or put this code in a template file and call the page and see what happens?

$button = $modules->get('InputfieldMarkup');

$button->value = "<a href='#'>markup test</a>";

echo $button->render();

if that fails there's no problem with MM but your PW install.

But then looking at you screenshot the other button made the same way work, so I'm confused.

[maba]

Debug in on, with error_reporting settings but.. no way.

No http, php (and mysql) errors.

PW logs are clean.

Yes, unbelievable. $modules->get fails only with this action.

Tried with 3 PHP version.

Copied a fresh "wire" folder: same issue.

// $button = $this->modules->get('InputfieldMarkup');

echo "URL: " . $this->page->url() . '<br>';
echo "D_URL: " . $module->download_url . '<br>';
echo "Module: " . $module->class_name . '<br>';
echo "Theme: " . $theme . '<br>';

$url = "{$this->page->url}download/?url={$module->download_url}&class={$module->class_name}{$theme}";

//$button->value = "<a href='$url'$confirm id='{$module->class_name}'>" . $this->_("download") . "</a>";

Works.. If I comment out $button.. the "loop" starts.

[maba]

if ($button = $this->modules->get('InputfieldMarkup'))
throw new WireException('Test Exception');

 TemplateFile: Test Exception
#0 /my/installation/path/site/modules/ModulesManager/ModulesManager.module(260): ModulesManager->getActions(Object(stdClass), false, 'download', '')
#1 /my/installation/path/wire/core/ProcessController.php(196): ModulesManager->execute()
#2 [internal function]: ProcessController->___execute()
#3 /my/installation/path/wire/core/Wire.php(359): call_user_func_array(Array, Array)
#4 /my/installation/path/wire/core/Wire.php(317): Wire->runHooks('execute', Array)
#5 /my/installation/path/wire/core/admin.php(49): Wire->__call('execute', Array)
#6 /my/installation/path/wire/core/admin.php(49): ProcessController->execute()
#7 /my/installation/path/site/templates-admin/controller.php(13): require('/my/installatio...')
#8 /my/installation/path/site/templates/admin.php(13): require('/my/installatio...')
#9 /my/installation/path/wire/core/TemplateFile.php(139): require('/my/installatio...')
#10 [internal function]: TemplateFile->___render()
#11 /my/installation/path/wire/core/Wire.php(359): call_user_func_array(Array, Array)
#12 /my/installation/path/wire/core/Wire.php(317): Wire->runHooks('render', Array)
#13 /my/installation/path/wire/modules/PageRender.module(333): Wire->__call('render', Array)
#14 /my/installation/path/wire/modules/PageRender.module(333): TemplateFile->render()
#15 [internal function]: PageRender->___renderPage(Object(HookEvent))
#16 /my/installation/path/wire/core/Wire.php(359): call_user_func_array(Array, Array)
#17 /my/installation/path/wire/core/Wire.php(317): Wire->runHooks('renderPage', Array)
#18 /my/installation/path/wire/core/Wire.php(381): Wire->__call('renderPage', Array)
#19 /my/installation/path/wire/core/Wire.php(381): PageRender->renderPage(Object(HookEvent))
#20 /my/installation/path/wire/core/Wire.php(317): Wire->runHooks('render', Array)
#21 /my/installation/path/wire/modules/Process/ProcessPageView.module(113): Wire->__call('render', Array)
#22 /my/installation/path/wire/modules/Process/ProcessPageView.module(113): Page->render()
#23 [internal function]: ProcessPageView->___execute()
#24 /my/installation/path/wire/core/Wire.php(359): call_user_func_array(Array, Array)
#25 /my/installation/path/wire/core/Wire.php(317): Wire->runHooks('execute', Array)
#26 /my/installation/path/index.php(192): Wire->__call('execute', Array)
#27 /my/installation/path/index.php(192): ProcessPageView->execute()
#28 {main}
 

Silly test.. PW works.

[Soma]

I'm not sure I understand what you're posting here last two posts. Anyone?

Since I can't reproduce nor see any wrong code I can't really do anything... also it looks like you're the only one experience this.

Anyone?