Forum Replies Created

Viewing 8 replies - 1 through 8 (of 8 total)
  • I have done quite a fair amount of additional customization work with this plugin and how it works with Gravity Forms. I happen to have built this exact feature which extends GF with an Advanced tab selector to either encrypt the stored data for a field or not, along with several other features including file storage encryption on-the-fly, improvements to hiding the encryption method, and an attempt at making the database stored GF encrypted data far less useful if someone gets it.

    In it’s current state, with symmetric encryption, the key is stored in the wp_options table. And the code for running the decryption routines are obviously right here…so I worked around that a bit.

    If the plugin author is willing, perhaps we could open it up and co-author / co-support it? I would consider adopting it too.

    I would have to spend a bit of time pulling all my changes together and getting them in shape for sharing though. 🙂

    Thread Starter brettv

    (@brettv)

    Good find from Phil Smart, that is pretty much exactly the issue, and a nice way of solving it without hacking on the module itself. Thanks.

    Thread Starter brettv

    (@brettv)

    Thanks for replying.

    I am already using the wpp_custom_html filter to customize the output, that was a thoughtful include on your part.

    The only issue regarding the “echo” return of the data is that the way I have used your plugin is that I needed to capture it’s output in order to feed it upstream to other page assembly mechanisms. In other words, I need the output from the WPP, but quietly, as all the page contents are not yet finished – more “partials” or “dynamic views” are being computed.

    Now, it has been a number of months since I did the integration, and I would be happy to look at doing it another way. Is there another way to trigger the functionality of WPP (which would include using the wpp_custom_html filter hook – which was a nice time saver) that did not immediately “echo” it’s output into the render chain?

    Here’s how to adjust the visual so it doesn’t look so broken when trying update a plugin.

    Open up the file sftp.php in the plugin directory.

    Look around line 143 for this:

    jQuery(‘form input[value=””]:first’).focus();

    Add this line immediately afterwards:

    jQuery(“.notification-dialog”).css({“top”:”2%”,”width”:”600px”});

    This will move the div dialog up the page a bit and make it wide enough to accommodate the form fields. Quick fix…

    I think this might only happen when updating a plugin, I saw what I think you described this morning when I updated something. The full screen version still appears when you upload a new plugin though.

    The SSH uploader still works, but you cannot hit the submit button and have to rely on the browser doing an auto-submit when you hit the return key.

    I believe this will fix the problems with these warnings.

    I traced the calling process through the system, and the rawlist() call returns an array indexed using the name of the file. It seemed the author assumed that using the array name itself would return index sub “0”. The other problem seems that WP might have changed the function call for delete, and the method definition parameters need to match the calling parameters.

    Here are the 2 simple adjustments that I do believe will fix the problems and make the warnings go away – they did for me.

    Open the file:

    /wp-content/plugins/ssh-sftp-updater-support/class-wp-filesystem-ssh2.php

    Find this line (around 218):
    function delete($file, $recursive = false) {

    And change it to this:
    function delete($file, $recursive = false, $type = false) {

    For the other error, find this block (at 316 and 317):
    $struc[‘owner’] = $this->owner($path.’/’.$entry, $entry[‘uid’]);
    $struc[‘group’] = $this->group($path.’/’.$entry, $entry[‘gid’]);

    and change it to this:
    $struc[‘owner’] = $this->owner($path . ‘/’ . key($entry), $entry[‘uid’]);
    $struc[‘group’] = $this->group($path . ‘/’ . key($entry), $entry[‘gid’]);

    If you have EventSpot enabled, this might fix it – as it seems to fix Visual Composer.

    After an hour or so of fun debugging, I figured out what this was.

    The fix for this conflict is:

    Edit the file:

    wp-content/plugins/constant-contact-api/lib/eventspot/embed.php

    Find this line near the top:

    add_action(‘admin_footer’, ‘eventspot_add_mce_popup’);

    Change it to this (priorities lower then 200 probably work, but I was pretty unhappy with it at this point and wanted to punish it with an “I-hate-you-now” low priority. Ha. )

    add_action(‘admin_footer’, ‘eventspot_add_mce_popup’, 200);

    After an hour or so of fun debugging, I figured out what this was.

    The fix for this conflict is:

    Edit the file:

    wp-content/plugins/constant-contact-api/lib/eventspot/embed.php

    Find this line near the top:

    add_action(‘admin_footer’, ‘eventspot_add_mce_popup’);

    Change it to this (priorities lower then 200 probably work, but I was pretty unhappy with it at this point and wanted to punish it with an “I-hate-you-now” low priority. Ha. )

    add_action(‘admin_footer’, ‘eventspot_add_mce_popup’, 200);

Viewing 8 replies - 1 through 8 (of 8 total)