admintiger

Further to my post above, the filepath isn’t valid because it is too long. File and folder names combined contain too many characters.

I unzipped the file under Linux without any difficulty. The problem under Windows isn’t due to a permission problem. It is that the wc-braintree.min.css filepath in the zip file isn’t a valid path under Windows.

I tried from that alternative URL using a different Windows 7 computer and the same thing happened. The zip file downloads with no problem, but the unzipping process hangs under Windows 7 with an error message about not being able to create a path to a .css file.

The developers complain that many negative reviewers aren’t referencing specific bugs or missing functionalities. They aren’t, because those things are trivial compared to the underlying problem. Bugs can be fixed and functionalities can be added, but none of that will fix the disastrous impact Gutenberg will have to the majority of users if it becomes part of the core. Focusing debate on trivial issues diverts it from what should be discussed, and that the developers do not want to discuss, so negative reviews that didn’t site trivial issues that can be fixed were deleted (though now, after censorship-complaints, are being restored).

The current WordPress editor has frustrating bugs or design flaws, depending on points of view, that should have been fixed long ago. There likely would be broad support for improvements, but Gutenberg will not be an improvement. It will be such a huge jump in the wrong direction that either WordPress will be forked or the majority will move to something else.

I also agree with klartext. The difficulty with using more than a couple words is that this will change WordPress so fundamentally that WordPress will become useless to those who want more than a mere blog. Explaining all that can be done with WordPress as it is now would require a huge book or even a volume of huge books. Explaining why this change of course will not be useful would require a similar huge book or volume of huge books. The developers already know what will be lost. If that knowledge hasn’t prevented them from going in this direction, explaining what they already know won’t change their minds.

It is obvious that they are easily distracted and are heading way off-course!

Admin menu characters are filled by black in some places on high resolution screens and are difficult to read. The font is ugly. White characters on a black background are ugly and make the UI look childish. Overall usability and aesthetics are awful compared to previous versions.

This is a version I am going to skip on multiple websites regardless of whatever security fixes it may contain. Hopefully, the developers will listen to users and revert back to the far superior previous design.

I also am having a problem with %GALLERY_NAME% not returning gallery names. In my case, rel=”photo[%GALLERY_NAME%]” becomes rel=”photo[set_1]”, rel=”photo[set_2]”, etc. in webpage HTML source code, where “set_1”, “set_2”, etc. are valid gallery names.

Great! I will give it a try tomorrow afternoon.

The “do not autoptimize” comment tags will be a valuable improvement, because they will make it possible to greatly reduce the number of cached files where inline js or css code changes from page-to-page. For example, I have a site that has about 5,000 content pages. Each of those pages has a single line of inline js code that is different from page-to-page, resulting in the creation of about 5,000 unique js files in the cache. Masking that single line with <!– noptimize –> … <!– /noptimize –> tags will make it possible for all those content pages to share a single js file. Not only will that greatly reduce the number of files cached on the server, but also will reduce visitor webpage loading times after any first page has been loaded.

The plugin information pages state: “Compatible up to: 3.4.2” That should be changed if the current version of Pronamic Google Maps is actually compatible with WordPress 3.6.

Ok, that’s reasonable.

If you want to learn more about it there is considerable information here https://yui.github.io/yuicompressor/. Even though most Autoptimize users probably haven’t understood its advantages or exactly how to enable it, the YUI Compressor is actually very easy to install and use with Autoptimize, especially under Linux. It is equally easy to install and works just as well under Windows, but a few simple modifications are needed to Autoptimize to make it compatible with the YUI Compressor under Windows.

Some WordPress plugins that fail using the PHP compression code in Autoptimize run fine using the external YUI Compressor.

I disagree that hackers love TML. To the contrary, its security features significantly reduce the risk that a hacker will be able to gain unauthorized admin system access. I have TML installed at several very active sites that are attacked by hackers and their bots 24/7. There has never been a successful unauthorized access.

I think it is likely that your site has some other vulnerability.

The new “Use Google Maps Visual Refresh” option in the current development version at the github repository works fine for me.

The problems I described above were found to be due to a conflict with the wp-pagenavi 2.83 plugin. I had selectively disabled all other plugins during initial troubleshooting, but had forgotten about the following function that had been added to the child theme functions.php file to support wp-pagenavi:

function twentyeleven_content_nav( $nav_id ) {
	global $wp_query;
	if ( $wp_query->max_num_pages > 1 ) : ?>
		<nav id="<?php echo $nav_id; ?>">
			<h3 class="assistive-text"><?php _e( 'Post navigation', 'twentyeleven' ); ?></h3>
      <?php wp_pagenavi(); ?>
		</nav><!-- #nav-above -->
	<?php endif;
}

Deactivating wp-pagenavi and removing that function corrected the problems. TML 6.3.8 now functions as advertized.