hommealone

Hey folks,

You put a faulty version of your plugin on line; let me know that it was available; heard that I was having trouble with it; then left for the weekend? Not cool.

Hey guys, I need a working version of the plugin. Can you send me an old version via email please so I can get my site back? I don’t care if the version is reported wrong for the time being! paul [at] insitewebsite (dot) com

After that update, my entire site crashed, including the admin back-end.

After my update 10 minutes ago, my plugins page now shows that I have version 3.1.2 and that 3.1.3 is now available. Will update to that and let you know…

Hi,

I just updated the plugin to the new version and I’m afraid I’m still getting 0.0

Sorry…

Thanks, middlesister. I’m very grateful for all of the great work that is going into the updating of Thematic.

For us, the responsive part was not really a concern; our child theme, based off Scott Nix’s responsive base and also making use of a responsive menu plugin, is already working fine, and I hope that the update will not in itself change too much for our child theme. As I understand, all of the elements that were there before, will still be available, especially if we were styling based on class names as much as possible. Our child theme doesn’t rely on @import of thematic css files, nor do we intend to use anything from the new main.css file in this case. (Although we are already designing some new sites with childthemes using it!) Thanks, though, for discussing that part of the equation, as it will probably be a question that comes into play with many child themes, especially those based on Thematic’s own samplechildtheme.

And because we were already using HTML5 markup thanks to the Thematic HTML5 plugin, I’m anticipating no major issues.

It sounds like we will just be able to do the Thematic theme update, disable the Thematic HTML5 plugin, check carefully for any issues, and make some (hopefully mostly minor) changes to our CSS if we find any changes. Very sweet!

Thanks again!

I’m having (what I think is) the same problem. When “adaptiveHeight” is set to false, the slider images appear squashed in width on small screens.

We’re using an ugly CSS + jQuery workaround. I don’t know if this will work for anyone else, but it does the job for us and allows the images and entire slider to scale properly.

In our CSS, we over-ride the img height that the plugin sets using this:

.bx-wrapper img {height: auto !important; max-height: 500px;}

I imagine that you could also give a different value, such as 300px.

That allows the images to scale down proportionally, but the viewport still gets messed up. So we use this jQuery to check the screen size and make adjustments:

jQuery(function ($) {
	/* You can safely use $ in this code block to reference jQuery */

$(document).ready(function(){
	// if there is a slider...
	if (".bxslider-gallery") {
		// get the width of the viewport...
		var bxviewportWidth = $(".bx-viewport").width();
		//// *the "bxSlider Integration for WordPress" plugin sets a height of 500px for the images in the slider;*
		//// *this causes problems with responsive designs if the "adaptiveHeight" option is set to false.*
		//// *In our CSS, we have overridden that with this: .bx-wrapper img {height: auto !important; max-height: 500px;}*
		// Enter the number that we use for the img max-height here...
		var imgMaxHeight = '500';
		// Check to see if the viewport is narrower than the max-height that we have set for images...
		if (bxviewportWidth < imgMaxHeight) {
			// If it is, we change the max-height of both the viewport and the image to fit into the smaller, square viewport...
			$(".bx-viewport, .bx-wrapper img").css("max-height", bxviewportWidth);
			// We also have trouble with the display of the pager on smaller screens so we adjust for that too...
			$(".bx-pager").css("bottom", "-70px");
		}
		// We also check and change these settings when the browser window is re-sized...
		$(window).resize(function() {
			var bxviewportWidth = $(".bx-viewport").width();
			if (bxviewportWidth < imgMaxHeight) {
				$(".bx-viewport, .bx-wrapper img").css("max-height", bxviewportWidth);
				$(".bx-pager").css("bottom", "-70px");
			} else {
				$(".bx-viewport, .bx-wrapper img").css("max-height", imgMaxHeight);
				$(".bx-pager").css("bottom", "-30px");
			}
		});
	}
})

}); // end jQuery function $

You can see that here:
https://www.katherinesolomon.com/petportraits

If anyone can suggest a better way or an improvement in this code, please do!

I’m also interested in any guess-timates of the time frame for the official release of the 2.0 Beta version.

I’ve been developing a site (for my own use) using the 2.0 Beta version and Scott Nix’s child theme with nice results so far, but have a few trepidations on using the Beta for a paying client. Any advise?

Also, will the 2.0 beta, when it is ready for public release, be released as an update to Thematic, or will it be released as a completely different theme?

Either way, If I develop using 2.0 Beta, will I be able to switch themes to the public final release by continuing to use my child theme (developed using the 2.0 Beta as its parent), but just setting it as a child of the public release version, rather than a child of the 2.0 Beta theme? (And ticking off any needed settings in the theme options, as I understand it.)

Thanks! And to all of you who are developing the new version: Great job!

Hi Ray,

Thanks for your response. I’m using the flat-rate shipping option. Here’s the problem…

My client is selling prints. Each [print] item in the store has a flat rate shipping amount of (let’s say) $5.00. If a customer wants to buy two prints, they get charged $10.00 for shipping in the shopping cart, even though the two prints could obviously go in the same envelope for one $5.00 shipping cost.

I haven’t been able to find a way, using the flat rate option, to apply one (only) flat rate amount to cover several items.

Any suggestions on how I might accomplish this?

While I was logged in, I could empty my cart, clear my cache, and whenever I would add a non-taxable item to my cart, it would always add tax anyway.

Well, I tried using a different browser (Chrome), and the checkout page showed no tax. Then went back to my original browser (Firefox), I logged out, and again added a non-taxable item to my cart, and then it didn’t add tax at checkout.

Then I logged in again, added a non-taxable item to my cart and proceeded to checkout. Again, tax was added.

Seems odd…? Anyone have an idea what is going on?

Well, I understand a bit more about all of the TinyMCE update issues now. And I understand that Josh wrote completely new code for a CodeMagic-like addition to his new WP Edit plugin.

So I now also know that the currently available version of the CodeMagic plugin would not be ready for any addition to a TinyMCE V4 WP plugin at this point anyway.

The CodeMagic developers report that they are working on an updated version but that it may take a while…

They say they will post updates here.

If you are interested, I have contacted the CodeMagic developers and they report that they are in the process of updating that plugin:

They say they will post updates here.

Josh,

My apologies. I guess this was just my frustration speaking, and I understand that mine is nothing compared to what you have experienced in this change over. You deserved better; sorry. And thanks for taking the time to explain this to an old crank like myself. I didn’t realize that the old/new Advanced HTML Code button issue was much more than simply “plugging in” the CodeMagic plugin into WP.

If I may ask one more question…? Is the CodeMagic TinyMCE plugin itself also now out of date (incompatible w/ the new version of TinyMCe)? You explained that you’ve written all new code for your new button. Just curious if you’ve spoken to the original developers or tried to work with them? Do you know whether they are re-writing theirs to work with TinyMCE 4?

Will the end user notice any difference between the old Advanced HTML Code button operation and the new one in WP Edit Pro?

Thanks again for your response; I’m sure you have more important things to do. And again, I’m sorry for shooting off my mouth without understanding the entire situation.

As a follow-up, I see this practice – of taking a previously free feature of a plugin (which people have spent time incorporating into their websites) and then moving the feature into a ‘payment required’ version – as a classic bait-and-switch tactic. I see this all too often, and IMO this gives not only the developer but WordPress itself a bad reputation.

If a plugin developer is going to develop a reputation by offering a great free plugin and then leverage that reputation in order to offer a “Pro” version, that is fine! But the Pro version should include only new or advanced features that were never in the standard version. Taking previously standard features and then charging for them has a bad smell to it.

Please excuse me if I have your motivations wrong! I truly appreciate all that you have done in developing this great plugin, and am extremely grateful to all plugin developers who offer their work to the public. That is what makes WordPress so terrific.

It is only the practice of moving existing features from a free version to a pay version that I don’t appreciate. People come to rely on the free feature, and shouldn’t have to wonder, when they first incorporate it, whether they will be able to rely on the developer to not yank it out from under them.

Our troubleshooting process, if it helps anyone else was the following.

The wrong address that IS being used is:

• NOT the name and address on the Settings > General page;
• NOT the name and address of the site admin (or any other user) – (searched the db using phpMyAdmin);
• NOT found on any settings pages including any of our plugins;
• NOT found at all in a search of our WordPress database (searched by using phpMyAdmin).

That led us to wonder where else the bad address might be coming from, so we searched our (long) functions.php file and found it in there. (Doh!)