cloudware

This problem continues to exist in WordPress 4.2.2 – it’s hurting.

Where is the code responsible for the sort order and how does it work?

If this patch basically produces a filename of time() rather than “/.maintenance” then surely the function of the site being shown to visitors as being under maintenance won’t work ?

I’m not sure but it would seem that WordPress would be looking for .maintenance not a variable number, and therefore visitors will continue to be able to use the site even when it should be ‘down for maintenance’ ?

The impact may be small in most cases but I think it should be known.

I don’t know the inner workings of WordPress well at all, I don’t even know why a tempname function need be so complex.

Keith

The problem is caused by the wp_tempnam() function in wp-admin/file.php

It recurses on itself and therefore php will run out of memory. This seems to be called when “enabling maintenance mode” so by deactivating the plugin first, presumably this will avoid maintenance mode.

Unfortunately it seems like a WordPress update itself requires maintenance mode, so this could get interesting when an update is released to fix the problem!

recursive call can be seen below ‘if the folder is falsey…’ – “return wp_tempnam(“…..

function wp_tempnam( $filename = '', $dir = '' ) {
        if ( empty( $dir ) ) {
                $dir = get_temp_dir();
        }

        if ( empty( $filename ) || '.' == $filename ) {
                $filename = time();
        }

        // Use the basename of the given file without the extension as the name for the temporary directory
        $temp_filename = basename( $filename );
        $temp_filename = preg_replace( '|\.[^.]*$|', '', $temp_filename );

        // If the folder is falsey, use it's parent directory name instead
        if ( ! $temp_filename ) {
                return wp_tempnam( dirname( $filename ), $dir );
        }

        $temp_filename .= '.tmp';
        $temp_filename = $dir . wp_unique_filename( $dir, $temp_filename );
        touch( $temp_filename );

        return $temp_filename;
}

Keith

Hi,

I’ve fixed this in the blanco theme by editing /wp-content/themes/blanco/wpsc-single_product.php around line 371 – add a class “wpsc-custom-meta” to the li element `( change
<li> to <li class=”wpsc-custom-meta”> )` :

<?php if (wpsc_have_custom_meta()) : ?>
                                <?php while ( wpsc_have_custom_meta() ) : wpsc_the_custom_meta(); ?>
                                <li class="wpsc-custom-meta">

then in a custom.css file, add the following:

.wpsc-custom-meta {
display:none !important;
}

As long as the custom.css is loaded, this should stop the custom meta from appearing, whilst still allowing the other tabs (short description, custom tabs for all products etc).

Really the problem appears to be that Revolution Slider should not be adding custom meta to Products – and the authors of that ought to fix that issue – at the bottom of Product editing screen Revolution Slider Options (slide_template: default) should have a ‘none’ option rather than defaulting to ‘default’ when there is no slide_template required against that product.

Keith

any thoughts?

any ideas?

Any update on this? (pardon the pun) ??