Modules Manager

[Soma]

The "fix" is just for something that is shown when debug mode on. I see, but you can actually grab that new module from github and upload it manually. Rare case, and I update minor version usually.

[Soma]

Little update 1.1.1

• added live search filtering, fuzzy text search only on name, author, categories and action
• some minor refactoring

[gebeer]

Hello and thanks for the nice ModulesManager module.

I'm running into a problem after deploying the site on the live server. When I open ModulesManager I get this error:

TemplateFile: cannot read cache file /is/htdocs/.../site/assets/cache/ModuleManager.cache

The file is there and its permissions are set to 640 so it should be readable by PW.

Any idea what might be the cause?

Thank you

gerhard

[gebeer]

I solved the probem by deleting ModuleManager.cache. After that ModulesManager started just fine and was rebuilding its cache file.

[Soma]

That looks like a permission issue with FTP and Apache/PHP user. As soon as you delete it PHP will create a new cache file and thus is again the owner.

[gebeer]

@Soma

I had already checked for the right Apache/PHP user and it was the owner of the cache file. So something else must have gone wrong.

[Joss]

This is probably plain silly, but have you tried re-transfering the file/folder again? Just in case it has dropped a byte or two somewhere on the floor ...

[Joe]

Hi. I just ran into an odd problem, not sure what happened:

First I updated a few modules using a previous modules manager version without any problem.

Then I updated the teppokoivula-ProcessLoginHistory with modules manager. After that the whole site was out and I got this E-Mail error notification:

Compile Error: Cannot redeclare class ProcessLoginHistoryHooks (line 22 of /xxx/xxx/xxx/xxx/site/modules/ProcessLoginHistory/ProcessLoginHistoryHooks.module)

^{(xxx = server specific, my server)}

I don´t know whether the problem here was caused by the module itself or the modules manager. I fixed it by replacing teppokoivula-ProcessLoginHistory with the previous version from my local install.

Now I don´t know if this is related, but after that I updated modules manager itself. Now it shows me "new version available!" messages for modules I´ve just previously updated, but there are no update-links for any modules, as there were before.

It is not a serious problem for me, as this is a test-install and of course I can update in the traditional way, but I wonder what might be the problem...

[teppo]

@Joe: could you provide the version numbers of ProcessLoginHistoryHooks that a) work for you and b) don't work? I'm not aware of any issues related to it, but I'd still like to make sure..

Edit: you mentioned "teppokoivula-ProcessLoginHistory" in your post above. Are you just referring to the module with this name or is this an actual directory in your /site/modules/?

Just making sure, 'cause having one module in two locations (such as /site/modules/teppokoivula-ProcessLoginHistory/ and /site/modules/ProcessLoginHistory/) would definitely cause this kind of issue.

Edited January 11, 2014 by teppo

[Joe]

Hi teppo, thanks for the quick reply

well, the folder in site/modules is "teppokoivula-ProcessLoginHistory-11af3f7" now. This is after the update, but I actually see in a previous install, that it is called the same there. No, there are not two folders for this module in the modules folder.

EDIT:

I boldly went ahead and tested updating Modules Manager on another version of my PW site... That went without a hitch.

After that I updated the ProcessLoginHistory module again, using Modules Manager and bang, the site was down again! Then I erased the ProcessLoginHistory module folder manually and de-installed the module: the site is working again.

Now I have installed the LoginHistory module, using Modules Manager, the install went without a problem and the LoginHistory module works.

To me there is no problem left and all I can say is that apparently there are circumstances under which an update of the LoginHistory module using Modules Manager fails, whereas a new install works. And when the update fails the site goes down completely (which I guess is of concern for future users, especially on a production site). By the way, the first occurrence was under the latest stable version, the second under one of the latest dev versions.

So it probably will be hard to pinpoint the problem. Anyway, both the ProcessLoginHistory module and the Modules Manager are good modules and seem to be working well!

Edited January 11, 2014 by Joe

[Soma]

These problems may arise when installing a module manually and then updating using modules manager. This mostly has to do with folder naming of the module. MM takes class name entered on modules directory so it's possible you named the folder different when manually installing a module. Not sure there is a good way to prevent that but if you install modules explicit with mm only this shouldn't be a problem.

[Joe]

Thanks, Soma, this is what happened, I´m almost sure. Anyway, as I wrote above, I have been easily able to fix the issue and to me it´s not a problem now. Maybe it might be good to include the above information with the module somewhere.

[Manfred62]

@soma

here are some upgrades for strings (translatable). Maybe better use some variables for repeating strings (like: 'more', 'installed: ') ?

line 239:
	$status = $this->_('found: ') . $local_version;

line 248:
	$status = '<span class="ui-state-installed">' . $this->_('installed: ').$local_version.'</span><br/>';
	$status .= '<span class="ui-state-update">' . $this->_('new version available!').'</span><br/>';

line 254:
	$status = '<span class="ui-state-installed">' . $this->_('installed: ').$local_version.'</span>';

line 284:
	$pretext = '<p>'.$this->_('Modules found on modules.processwire.com (').$count.') </p>';

line 498:
	return $this->_('(uninstallable)').'<br/><a href="'.$module->url.'" target="_blank" title="'.
	$this->_('Uninstallable with Modules Manager').'">'.
	$this->_('more').'</a>';

line 541+1:
	$actions = "<button name='install' value='{$module->class_name}'>" . $this->_("install") . "</button>";

line 543+1:
	$actions = '<a href="'.$module->url.'" target="_blank" title="'.$this->_('No download URL found').'">'.
	$this->_('more').'</a>';

[Soma]

I'm proud to announce a "major" update to 2.0.0.

I spent most of the weekend to make some changes, that makes it more convenient to browse, download, update, install and edit module from within ModulesManager.

Change log 2.0.0

• added jQuery DataTables to list modules. This enables convenient browsing with pagination, live search filter and sorting. State saving via cookies is enabled so if you come back it shows the table how you left it.
• added iframe modals for download, update, edit and install links. So you can now install modules without leaving the ModulesManager page. This is using Magnific lightbox by default, if installed, otherwise it will take the older Fancybox.
• some more translations added

Update Note: This version requires you to install JqueryDataTables module before you will be able to use the new 2.0.0.

I hope I haven't forgot something on the way. My tests so far went well and everything still works as before, just a little more awesome

Thanks and enjoy the rest of the weekend.

[Martijn Geerts]

Big thanks !

[kongondo]

+1 for "modals:  install modules without leaving the ModulesManager page"

[adrian]

Hey Soma this sounds great, but I just installed JQueryDataTables which installed fine, but then I went to upgrade the ModulesManager and got this error:

Warning: chmod(): Operation not permitted in xxx/wire/core/Functions.php on line 187

and this message whenever I try to open the modules manager:

ModulesManager: ModulesManager requires 'JqueryDataTables' module since version 2.0.

Any ideas?

[Soma]

If this message shows up JqueryDataTables isn't really installed then. I just installed update to various installs and works fine.

That first message is rather strange.

[adrian]

DataTables is working - see attached. v 1.0.0

[kongondo]

Adrian, did u install the new DT module (1.9.4) or the old one? (1.0.0) That looks like the old one ?

Edited for clarity:

In case you didn't know, these are different modules (one does not replace the other!)

Edited January 19, 2014 by kongondo

[Soma]

if(!$this->modules->isInstalled("JqueryDataTables")){
    $this->error($this->_("ModulesManager requires 'JqueryDataTables' module since version 2.0."));
    return;
}
 

The one who can read is clearly advantaged

[adrian]

Thanks kongondo - I didn't read things properly and assumed that the new data tables plugin would override the old one. I uninstalled the old, installed the new and the modules manager is working again!

[Soma]

There's no old and new one.

DataTables was a proof of concept integrating it in a admin page. It included the jQuery DataTables plugin, but unfortunately it may wasn't a good way to.

JqueryDataTables is a js module like Fancybox. It is a "integration" of the jquery plugin for developers to use datatables in their modules. It won't be loaded unless you do so. An example would be the ModulesManager.

They can coexist if you will.

[kongondo]

...yes, they are different beasts 

I was just about to clarify that...will edit my post above...

@Soma...maybe you want to make the above clearER in the JqueryDataTables thread? 

Edited January 19, 2014 by kongondo

[Soma]

@Soma...maybe you want to make the above clearER in the JqueryDataTables thread? 

I thought I did. But maybe a clarification wouldn't hurt. Also I'm maybe going to delete the DataTables module..