Forum Replies Created

Viewing 4 replies - 1 through 4 (of 4 total)
  • Thread Starter apaschou

    (@apaschou)

    Hi,

    Thanks for your answer. I tested with your developer version, which looked promising. However, at first try, the plug-in entered in a loop with the two message below:
    NFO 2017/05/06 06:37:57 Copying wp_cimy_uef_data as wpstg2_cimy_uef_data between 0 to 0 records
    INFO 2017/05/06 06:37:58 wpstg2_cimy_uef_data already exists, dropping it first

    To avoid being blocked and allowing the test, I deselected all tables and relaunched the process. The blue bar goes of “Copy database tables” goes quickly to the end… and then nothing happens. The working log remain empty, the bars don’t move, when the cycling arrow just continues to turn.

    I think that the development version is not yet ready for this test.

    Best regards.

    Hi,

    Thanks for your answer. Sorry for the strange words used, but my WordPress in installed in french and I have to guess the equivalent in English… so yes, I am speaking about “permalinks” and yes “Plain” is the (completely wrong) translation of “Default”.

    I read the link you provided. I have an Apache server, and according to what I read, having the mod_rewrite module installed is one of the requirements to have “Pretty Permalinks”. I tested the mod_rewrite from a php script, and it is active at the root directory where I installed WordPress.

    Another one is the “Followsymlinks” directive. I added it in a .htaccess file at the root of the wordpress site. This didn’t change anything.

    Then I added the “AllowOverride All” directive, which transformed the 404 error in a “Internal server error”.

    Finally, I read somewhere that WordPress is supposed to adapt the .htaccess with the necessary configuration based on the type of permalink we select. On my case, this wasn’t done due to missing write rights in the root directory for WordPress. That is the reason why it didn’t work. Finally, the following configuration was added by WordPress in the .htaccess file (after I solved the write limitation issue):

    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /my_root_directory/
    RewriteRule ^index\.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /my_root_directory/index.php [L]
    </IfModule>

    Now everything is working fine.

    Regards.

    Hi,

    I got exactly the same issue as described above. I think that ALL servers manage special characters but, as you mentioned, they may be configured differently (UTF-8, ISO 8859-1, etc.). It is not easy to know which is the configuration of the server, but there should have a way to understand what is expected by the plug-in. I typically have a server with many files. I configured manually the FTP software to display correctly the special characters. The typically working encoding are “windows-1252” or “ISO 8859-1”. But displaying the same files on File Ways shows me strange characters. Finally, I discovered that if I configure the FTP to send file names in UTF-8 on the server, then File Away is displaying them correctly. For me, this is coherent as the whole WordPress encoding is UTF-8 (<meta charset=”UTF-8″>). Maybe there are some other possible configurations. But I would recommend to send files on the server using UTF-8 encoding if it doesn’t work with usual Windows character set.

    Regards.

    Hi,

    I asked myself the same question. I arrived to the conclusion that it is stored in table “wp_petition_signatures” in the field “fields”. However, the plug-in seems to encode it in a special way. I could prove it was stored there because I change one character, and my additional field content was no more appearing in the signature list (signature was still there). Looking at the code, it seems it is using “base64_encode” php function to store the data.

    Regards.

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