jqz

Dear WordPress,

Please support Markdown here instead of pseudo-HTML. In 2019, no-one expects HTML entered in a comment to actually persist.

J_

Closed as duplicate.

What you are producing is invalid HTML. The only allowed children of ul are li. I’m referring to a div with class berocket_lgv_additional_data.

Sorry if there are multiple posts but struggled with wordpress.org mangling the title and content.

The feature should indeed now be automatically activated for you when you first install Jetpack.

I tested again (uninstall and reinstall) and it still isn’t (it becomes deactivated).

At the bottom of the Debug page that loads, click to access the full module list.

I don’t see anything to click to access the full module list. I am using Jetpack in development mode, so the debug page says “It looks like your site cannot communicate properly with Jetpack.” Is it not possible to access the full module list from the Debug page when using Jetpack in development mode? And/or could development mode be the reason the feature isn’t automatically activated?

The WordPress front page is set to the same as the WooCommerce Shop page, so it sounds like it’s the same as the referenced issue.

I tried all 5 options for ‘fit’ to no avail, clearing cached images between each try. Different results are produced, but all with extraneous white borders.

The documentation only ever talks about scaling images down. Whilst I don’t think images should be scaled up—as it causes unnecessary bandwidth and should be the job of the browser/CSS to do this—I do think the code should be able to handle the case where the source image is smaller than the designated target, by producing an image smaller than requested that can be scaled up by the browser/CSS e.g. via a width style attribute.

For now I will stick with modified source code (as above) and take care when upgrading, but would like to know (via a post on this thread) when a fix for the issue is applied.

On a side-note, I think that your image handling is a an order of magnitude better than the WordPress default (it appears to work seamlessly moving a site to a different domain, and has the flexibility of supporting any image size rather than a predefined list of sizes), so I am glad I don’t have that headache.

Some more frustrations that wasted hours of my time:

1. After changing the WordPress image ‘insert into post’ setting to ‘no link’, adding or changing category images was broken: the dialog would not close properly, and even inserting the URL directly resulted in no image when viewed on the actual site (though it did appear on the admin edit page). Seems I need to click on ‘File URL’ to get the URL for it to work, but that’s far from obvious.

2. Possibly due to WordPress import/export tools, I arrived at a situation where a custom field for a location was broken, and could not be edited or removed in the editor, so I had to create a new location (the same), set all events to this, and delete the original. The field data that caused the problem was:

a:2:{i:0;s:45:”[original_value]”;i:1;s:45:”[original_value]”;}a:2:{i:0;s:45:”[original_value]”;i:1;s:45:”[original_value]”;}

(where [original_value] was the value that was put in). Don’t know what added all the extra crud, but it essentially broke the editor.