Jump to content

Modules Manager


Soma

Recommended Posts

little update, big improvements afte little more testing.

1.0.3

- Language Packs and Site Profiles now show up but will have a "more" link to the repository page.

- Added check if no download github url found to give a "more" link to the modules url
Link to comment
Share on other sites

Hey Soma,

I get an error when I wanna switch admin theme:

Error Call to undefined function wireRmdir() (line 358 of /share/HDA_DATA/Web/pwSpielwiese/site/modules/somatonic-ModulesManager-028cd65/ModulesManager.module)
Link to comment
Share on other sites

Ups. Pete is right it requires 2.3 because of new remove dir function. Completly forgot about it. Hm not sure what to do

Should I remove it?

Joss Im not sure whats about that. Is it working or not if you update it?

Link to comment
Share on other sites

@Joss, I think I know what happens to you. 

Version is the latest version of the module.

Status is the version you have installed.

If you update and it says it's sucessful, but the status still shows the old and an update link there must be a write permission problem.

It have the same issue in my local testing server (don't know how to correct the permission really), when I have a module that I installed manually originally and try to update it via modules manager. So it seems you have the same issue. What I have to do in this case is change the files permission to be writeable and it then works.

Link to comment
Share on other sites

Hey, not sure, if it's helping but here's the unzip function I'm using for my AuoUpgrade module:

private function unzip($file){ 
$zip = zip_open($file); 
if(is_resource($zip)){ 
$tree = ""; 
$i = 0;
while(($zip_entry = zip_read($zip)) !== false){ 
//echo "Unpacking ".zip_entry_name($zip_entry)."\n"; 
if(strpos(zip_entry_name($zip_entry), DIRECTORY_SEPARATOR) !== false){ 
$last = strrpos(zip_entry_name($zip_entry), DIRECTORY_SEPARATOR); 
$dir = substr(zip_entry_name($zip_entry), 0, $last); 
$file = substr(zip_entry_name($zip_entry), strrpos(zip_entry_name($zip_entry), DIRECTORY_SEPARATOR)+1); 
if(!is_dir($dir)){ 
if($i == 0) {
$first_folder = $dir;
}
@mkdir($dir, 0755, true) or die("Unable to create $dir\n"); 
} 
if(strlen(trim($file)) > 0){ 
$return = @file_put_contents($dir."/".$file, zip_entry_read($zip_entry, zip_entry_filesize($zip_entry))); 
if($return === false){ 
die("Unable to write file $dir/$file\n"); 
} 
} 
} else { 
file_put_contents($file, zip_entry_read($zip_entry, zip_entry_filesize($zip_entry))); 
} 
$i++;
} 
return $first_folder;
} else { 
echo "Unable to open zip file\n"; 
return false;
} 
}
Link to comment
Share on other sites

Soma, here's what I did in FormBuilder, which also requires wireRmdir:

/**
 * Temporary, until Form Builder requires PW 2.3
 *
 */
if(!function_exists('wireRmdir')):
        /**
         * Remove a directory
         * 
         * @param string $path
         * @param bool $recursive If set to true, all files and directories in $path will be recursively removed as well.
         * @return bool
         *
         */
        function wireRmdir($path, $recursive = false) {
                if(!is_dir($path)) return false;
                if($recursive) {
                        $files = scandir($path);
                        if(is_array($files)) foreach($files as $file) {
                                if($file == '.' || $file == '..') continue;
                                $pathname = "$path/$file";
                                if(is_dir($pathname)) {
                                        wireRmdir($pathname, true);
                                } else {
                                        unlink($pathname);
                                }
                        }
                }
                return rmdir($path);
        }

endif;


Always be very careful with wireRmdir and check everything you send to it to make sure it's correct and not blank, etc. This function always scares me a bit. The wireRmdir function will empty your entire file system if told to. :) 

  • Like 2
Link to comment
Share on other sites

Thanks @Ryan. Looking at my module again, I seem to have missed that I already have a recursive remove dir function I used. I just forgot about since it's some time ago already I implemented that. Baaah, shame on me :D I'll update the module again to correct that.

Yeah for future version. It's might be cool to have a version check to see if a module support the installed PW version.

@Nico. I'm not sure. Does the zip extract not work for you? I already have a much simpler zip extract function, but thanks anyway. At least, it remembers me to implement DIRECTORY_SEPARATOR too.

  • Like 1
Link to comment
Share on other sites

Thanks Ryan. 

I'm still up with including Modules Manager in the core, but I'm trying hard to imagine how to go for it and what all the features are that are absolutely needed and super important. We discussed this already some in this thread and I still couldn't make up my mind thinking about it.

However One thing is sure that it should still work the way it is now and let you install modules without internet access (local environement). But the way it works now this is already possible and it is no problem I think. √ I don't think an alternative "upload" function via a form is a good way, as you already can put it manually in such a case (already have it locally for example)

Now working on the module a little and thinking about versions. How should we handle this all if at all? 

Module Version:

There's a module version that have to be different to recognize an update and output a action link according. By now it just replaces the folder. What if the new version doesn't work and. In short, would some version management make sense here, with rollback etc? I think this would be harder and a lot more work to implement.

But also thinking about managing modules through such a interface with direct downloading may really need such features as a "manifest" for the module with update instruction that can be displayed while installing and make some of those thing required for PW modules. Rather now than later. Currently there's no way to implement a good system without it. There's some idea's but I can't make it up myself.

Module PW version compatibility:

On modules.processwire.com you can select for what versions of PW the module works. Which is cool. But currently when there's a new PW version option there like the 2.3, almost all modules don't have this checked. So now checking for the version on PW locally and the ones of the modules wouldn't work so well as there're only one of mine that has it checked. What you think? Some soft notification that it may not work? Not really. But I don't see a nice solution to this issue, maybe otherthinking it.

  • Like 1
Link to comment
Share on other sites

Rollback (and roll forward) is a great idea, but yes that would be more work :) A way to do it is have a /site/archived-modules/ folder and stick the older versions in there by module name and then by version.

What are you thinking in terms of the manifest?

Link to comment
Share on other sites

I'm not sure manifest is the right word. I mean make up some conventions that will help making the install process more convenient.

That would contain certain infos about the version it's compatible with maybe important update instructions along with the version, currently it's done via modules.processwire.com which is cool but not enough. 

Link to comment
Share on other sites

I'm still up with including Modules Manager in the core, but I'm trying hard to imagine how to go for it and what all the features are that are absolutely needed and super important.

We'll start simple. The only things that matter much to me for the core inclusion are just getting it to the point where we don't have to worry what happens as scale increases. Though since the modules manager can upgrade itself, even this may not be crucial. I'm thinking it'll still live in /site/modules/ModulesManager/ but just be included with the default profile(s) distributed with PW, on the file system, but uninstalled. Once we've got it as an integral part of the Modules tab, then it would always be installed, but that can come later. 

I also think we've got to have even more disclaimers in there, warning people about the dangers, especially on a production server. The reality is that should one of our module authors turn to the dark side, they could take control over any sites running their module by just inserting malicious code and updating the version number. The next time someone updates, bam! Beyond just warnings/disclaimers, we probably need to pursue a "verified by ProcessWire team" label for quality assurance and safety. But this is longer term...

However One thing is sure that it should still work the way it is now and let you install modules without internet access (local environement).

Of course, will always support that. 

I think. √ I don't think an alternative "upload" function via a form is a good way, as you already can put it manually in such a case (already have it locally for example)

I agree. It might have sounded good at one point, but I don't think we need that either. 

There's a module version that have to be different to recognize an update and output a action link according. By now it just replaces the folder. What if the new version doesn't work and. In short, would some version management make sense here, with rollback etc? I think this would be harder and a lot more work to implement.

Rollback would be nice to have in the longer term. In the shorter term, I think it would be adequate to say "Warning: Installing new modules can break your system. You should always backup your database and /site/ directory before installing new modules or upgrading existing modules." 

But also thinking about managing modules through such a interface with direct downloading may really need such features as a "manifest" for the module with update instruction that can be displayed while installing and make some of those thing required for PW modules.

I will update the module dependency system to support specification of required version of modules. Currently it just lets you specify required modules. Since PW itself won't install modules lacking dependencies, I don't think the dependency system has to be built into the modules manager at this stage.

On modules.processwire.com you can select for what versions of PW the module works. Which is cool. But currently when there's a new PW version option there like the 2.3, almost all modules don't have this checked.

Good point. Modules Manager should not probably not consider version number at this point in time then. Especially since once a module works in PW, it tends to usually work in future versions. Required PW version won't be a factor initially, since Modules Manager won't be included until 2.3 dev or 2.4. We can just refer to these versions as "known working with" versions. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...