Forum Replies Created

Viewing 15 replies - 1 through 15 (of 15 total)
  • I do not agree with the idea that the infection was on your dev pc first. You probably got it after your WP site got infected.

    However, it happened to one of my sites too. Looking at the server logs, this is what happened:

    [06/Oct/2015:06:16:22 +0200] "POST /wp-login.php HTTP/1.0" 302 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0"
    
    [06/Oct/2015:06:16:24 +0200] "GET /wp-admin/plugin-install.php?tab=upload HTTP/1.0" 200 128092 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0"
    
    [06/Oct/2015:06:16:28 +0200] "POST /wp-admin/update.php?action=upload-plugin HTTP/1.0" 200 123382 "http://www.nuapua.com/wp-admin/plugin-install.php?tab=upload" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0"

    So what happened?
    – the intruder knew an admin user/pwd combination. How this happened is being investigated at the momen.
    – he uploaded a plugin file called ‘options.php’.

    An hour and a half later, he started to execute the uploaded file(s) and spread the infection:

    [06/Oct/2015:07:42:59 +0200] "POST /options.php HTTP/1.0" 200 1 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0"
    
    [06/Oct/2015:07:42:59 +0200] "GET /options.php?cookie=1 HTTP/1.0" 200 1 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" 
    
    [06/Oct/2015:07:42:59 +0200] "POST /wp-content/options.php HTTP/1.0" 200 1 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" 
    
    [06/Oct/2015:07:43:00 +0200] "GET /wp-content/options.php?cookie=1 HTTP/1.0" 200 1 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0"
    [06/Oct/2015:07:43:00 +0200] "POST /wp-content/plugins/options.php HTTP/1.0" 200 1 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" 
    
    [06/Oct/2015:07:43:00 +0200] "GET /wp-content/plugins/options.php?cookie=1 HTTP/1.0" 200 1 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" 
    
    [06/Oct/2015:07:43:00 +0200] "POST /wp-content/themes/options.php HTTP/1.0" 200 1 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" 
    
    [06/Oct/2015:07:43:00 +0200] "GET /wp-content/themes/options.php?cookie=1 HTTP/1.0" 200 1 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0"
    [06/Oct/2015:07:43:01 +0200] "POST /wp-content/upgrade/options.php HTTP/1.0" 200 1 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" 
    
    [06/Oct/2015:07:43:01 +0200] "GET /wp-content/upgrade/options.php?cookie=1 HTTP/1.0" 200 1 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" 
    
    [06/Oct/2015:07:43:01 +0200] "POST /wp-content/uploads/options.php HTTP/1.0" 200 1 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" 
    
    [06/Oct/2015:07:43:02 +0200] "GET /wp-content/uploads/options.php?cookie=1 HTTP/1.0" 200 8 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0"

    I then ended up with a WP install with corrupted header.php of the active theme and a lot of modified plugin and core files.

    Just reverting back the header.php IS NOT ENOUGH. There are going to be modified and additionally uploaded files everywhere throughout the whole WP install.

    You need to find and repair/delete all modified files, otherwise your WP install will never be safe again.

    You might one to try a plugin like WordFence to clean up you site and search for infected files.

    Thread Starter m1ndmaker

    (@m1ndmaker)

    So here’s the answer:

    WP-Memory-Usage uses ini_get(‘memory_limit’),

    Your plugin uses the constant WP_MEMORY_LIMIT.

    To have both show the same amount, both constants WP_MEMORY_LIMIT as well as WP_MAX_MEMORY_LIMIT need to be set in wp-config.php:

    define( 'WP_MEMORY_LIMIT', '140M' );
    define( 'WP_MAX_MEMORY_LIMIT', '140M' );

    Best

    Michael

    Thread Starter m1ndmaker

    (@m1ndmaker)

    Thanks Ewout,

    Meanwhile I built in the total number of pages using inline PHP. A CSS statement like counter(pages) would be the ideal solution.

    In case someone can make use of the code, the following prints the total number of pages to the bottom center of the current page (inline PHP has to be enabled).

    <script type="text/php">
      if ( isset($pdf) ) {
        $pdf->page_script('
          if ($PAGE_COUNT > 1) {
            $font = Font_Metrics::get_font("Arial", "normal");
            $size = 7;
            $pageText = "Page " . $PAGE_NUM . " of " . $PAGE_COUNT;
            $y = $pdf->get_height() - 80;
            $x = ($pdf->get_width() - Font_Metrics::get_text_width($pageText, $font, $size) ) / 2 ;
            $pdf->text($x, $y, $pageText, $font, $size);
          }
        ');
      }
    </script>

    It is quite important to have a total number of pages on a document like an invoice. Our current customer insisted to include it, and it is actually a fair point as invoices are being used for tax verifying and VAT reporting.

    Best

    Michael

    Thread Starter m1ndmaker

    (@m1ndmaker)

    You are right, the DomPDF version on github has a 4 months old last commit. In some of the forum entries they wrote, they would include a total number of pages fix in 0.6. What version are you using? I could not find a version number in any of the DomPDF lib phps…?

    I do understand the problems involved when switching the library. However, an invoice generation plugin without the capability of displaying the total number of pages is, simply put, more than disappointing.

    Best

    Michael

    Thread Starter m1ndmaker

    (@m1ndmaker)

    Please be so kind and read my posts.

    I found out the Webbrowser caches the ajax results. Not wordpress.

    WordPress could avoid that caching by setting the ‘cache‘ setting in the jQuery ajax call to false. That would probably solve it, but increase the traffic.

    Thread Starter m1ndmaker

    (@m1ndmaker)

    32	        // wp.ajax
    33	        // ------
    34	        //
    35	        // Tools for sending ajax requests with JSON responses and built in error handling.
    36	        // Mirrors and wraps jQuery's ajax APIs.

    https://core.trac.wordpress.org/browser/branches/3.8/src/wp-includes/js/wp-util.js

    Line 32.

    This class is being used for sending AJAX requests in the media browser/uploader. It is a wrapper for the jQuery .ajax() function: wp.ajax.send() calls $.ajax().

    Thread Starter m1ndmaker

    (@m1ndmaker)

    Of course not. There are no files called wordpress-screenshots-x. This was an example to illustrate the behaviour.

    However, I came to the conclusion it is not wordpress caching the search results, it is the browser (Firefox 26 in my case). It looks to me like the WordPress AJAX wrapper for the jQuery .ajax() function does use the default value for the setting cache, which is set to true. The search results are therefor being cached in the browser cache like every other web page as well. Unfortunately without the possibility to press F5.

    Looks like there is no way I could change this behaviour other than editing the corresponding files in wp-includes/. Which I of course don’t want to get on with.

    It would be nice to have some kind of refresh button in the media uploader – clicking on it could perform an ajax request with cache set to false – and would therefor update the search results.

    Maybe I can find a way round to perform this using a plugin hook. Let’s see.

    Thread Starter m1ndmaker

    (@m1ndmaker)

    Right. That answer was equally useful as no answer at all, thanks for that.

    I’m writing themes and plugins for wordpress since 2.2. I think I have left the ‘Getting started’ part behind a while ago.

    If you can’t provide proactive and helpful answers, I recommend you don’t.

    “Comments can be disabled according to post type.”

    It does exactly what you want. I’m using this plugin myself for exactly this purpose.

    Find the according CSS file of the theme, in there find the style for h1.title with the line-height attribute and change it to something you like.

    Have a look at the safe-redirect-manager plugin. It is made for exactly this purpose – redirecting “old” URLs to the new permalink.

    http://wordpress.org/plugins/safe-redirect-manager/

    Have a look at

    http://wordpress.org/plugins/disable-comments/

    It offers the option to turn off comments on various post types (e.g. attachments), without editing the theme.

    Forum: Fixing WordPress
    In reply to: Site has gone 404!

    Running a website on a DDNS webserver is not the best idea. If you do this, you need to use your public domain name rather than any IP address. If using DDNS your publicIP might change and internal IPs are not being routed in the public internet.

    However, to correct this:

    • 1) The WordPress URL set in the settings page should point to your DDNS address.
    • 2) You need to update all posts, pages etc that contain links or images referring to the wrong (internal) IP address. All occurances of the wrong IP need to be replaced with the correct public domain name.
    • 3) There is a very handy tool out there to do exactly this task for you
      http://interconnectit.com/products/search-and-replace-for-wordpress-databases/

    If this sounds too complicated I recommend you delete your MySQL tables and reinstall wordpress, using your public domain name for the wordpress URL.

    As WP 3.6 uses jQuery 1.10.x, silly Comprehensive Google Map Plugin thinks it is < 1.3.0.

    Should ASAP use decent version checking or get rid of the jQuery version check anyway.

    Same here. Annoying.

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