Unable to delete Packages

It may be permission related. If you want to submit a support ticket I can try and take a look at your site if you want…

Ive never had this problem b4. There seems to be a lot of updates happening within last 6 months.

I haven’t changed any settings since I started using 1 yr ago.

I wont be letting anyone into my site period, so if there’s something going on Id like to know what the changes have been made within the updates ?

I can delete them from within cPanel, but then again its not even showing up in the Duplicator packages been removed.

Think someone may wanna do some tests on yr own stuff see whats happening

• This reply was modified 7 years, 8 months ago by jasonb4u2.

Hey Jason,

Sorry your running into this issue… I’m not sure why that may be happening in your environment. My only guess is that the PHP user your server is running under is unable to call the unlink command. That of course is a guess as there could be an assortment of other issues but its difficult to speculate when we haven’t been able to repro the issue in any of our environments.

We currently run Unit tests against 3 separate VPNs and 4 separate major hosting providers along side several development boxes… The code is open to the community to help isolate these types of issues and your welcome to checkout the changes that have been made.

The plugin continually has updates as we are always trying to fix and improve issues that users in the community run up against and find ways to improve the overall workflow. If you find anything please let us know and we’ll work to get it updated.

Thanks~

Hey Cory,

I encountered the same problem as Jason and could not delete any packages.

I traced the issue through to the fact that the wrong dialog was being displayed from the Packages page ($alert1 in packages.php instead of $confirm1 in packages.php) even though at least one package had been selected and the “Bulk Action” had been set to Delete.

From looking at the rendered Package page the three possible dialog boxes ($alert1, $alert2 and $confirm1) all had the same id, so $alert1 was being displayed each time the Apply button was clicked.

It appears that the issue is down to the use of uniqid() function in the constructor for the DUP_UI_Dialog class (class.ui.dialog.php) which was not guaranteeing uniqueness for the dialog ids from our server.

As a workaround I used the more_entropy parameter on the uniqid() function and truncated the result to 14 characters (i.e. all the characters before the decimal place). This seems to have fixed the problem and provides uniqueness for all dialogs.

This workaround involves changing the constructor for the DUP_UI_Dialog class

    public function __construct()
    {
        add_thickbox();
        $this->progressText = __('Processing please wait...', 'duplicator');
        $this->uniqid       = uniqid();
        $this->id           = 'dup-dlg-'.$this->uniqid;
    }

As shown below…

    public function __construct()
    {
        add_thickbox();
        $this->progressText = __('Processing please wait...', 'duplicator');
        $this->uniqid       = substr(uniqid('',True),0,14);
        $this->id           = 'dup-dlg-'.$this->uniqid;
    }

Thanks

• This reply was modified 7 years, 8 months ago by jwilmot.

Very nice @jwilmot! Thanks for providing the source, we don’t get that very often… Let me know if you want me to add you to the git-hub repro as a contributor.

I have committed this to the trunk so you should be able to download latest version (1.2.1).

Let me know if you run into any issues.
I’ll try and get this pushed out to community in the next few weeks…

Thanks Again~

• This reply was modified 7 years, 8 months ago by Cory Lamle. Reason: spelling
• This reply was modified 7 years, 8 months ago by Cory Lamle. Reason: spelling