williampatton

Hey @destination22

The images in your screenshots show what is the the mobile version of the site.

Many themes are more ‘responsive’ to the screensize of the device – rather than actual distinctive ‘mobile version’. Being ‘responsive’ tends to mean that different parts of the page either collapse or go full width to make everything sit nicely on the page in a readable way at different sizes of screen.

If you open up the site on PC and resize your browser window down to a size under 640px wide you will see a similar version of the site as what is in the google mobile friendly test.

It’s almost always the theme that decides how things behave on mobile (with exception to some plugins specifically made specifically to have a to give a distinctively different version of the site to mobile users).

If have a specific behavior in mind that this theme doesn’t do then let me know and I may be able to suggest an alternative that does what you need.

Edit: I took a quick look and the screensizes of an iphone7 is 1334px x 750px and the size of the Oneplusone two is 1080px x 1920px. This theme goes into the mobile mode shown by google at 640px. Both those phones have larger screen sizes than what this theme goes to the mobile version for.

• This reply was modified 6 years, 11 months ago by williampatton.
• This reply was modified 6 years, 11 months ago by williampatton.

EDIT: or yeah just do what otto says, that’s easier method ??

Hey @skyspec,

Did you place the code at the start or at the end of the functions.php file?

TwentySeventeen theme adds it’s own version of this function to the theme which sets the sizes to be 1em for largest and smallest values.

The filter function I posted above needs to run after that function. You can make that happen by placing the function at the end of the file, or by setting a priority that puts it later in the firing than 10 in the add_filter() call like so:

add_filter( 'widget_tag_cloud_args', 'prefix_custom_tag_cloud_widget', 20 );

I’ve just tested and confirmed both methods work with WP v4.9 and TwentySeventeen v1.4.

• This reply was modified 7 years ago by williampatton.

Hey @skyspec,

Maybe the behavior you are after can be achieved with this filter function. Add it to your functions.php file of your theme and it should size tags accordingly between the largest and smallest size stated based on the weight the tag has in the cloud.

if ( ! function_exists( 'prefix_custom_tag_cloud_widget' ) ) {
	/**
	 * Custom tagcloud tweaks
	 *
	 * @param  array $args 	Array of args already passed to tagcloud widget.
	 *
	 * @return array 		Updated array with more args appended or udpated.
	 */
	function prefix_custom_tag_cloud_widget( $args ) {
		$args['largest'] = 21;
		$args['smallest'] = 14;
		$args['unit'] = 'px';
		return $args;
	}
}
add_filter( 'widget_tag_cloud_args', 'prefix_custom_tag_cloud_widget' );

• This reply was modified 7 years ago by williampatton. Reason: code formating
• This reply was modified 7 years ago by williampatton.

@pressgang

Yes I think it is probably somewhere inside the wp-includes directory that has something unusual going on. Manually override that directory when your uploading the latest version manually may be all that is needed to fix the problem.

So far there hasn’t been a huge number of reports of failed install and a large number of sites (my own sites included) updated without any problems. I’m not sure where your exact problem comes from but if we can figure it out then that may be able to help the next person who comes across this problem ??

In FileZilla you can see the permission numbers and if they are all matching then it would be strange that a certain file would be set differently. Depending on your connection type you might also be able to turn on another field in FileZilla to show the file owner and the group (if you are connecting with SSH/SFTP you could see this, standard FTP it won’t show). Sometimes with 1click installers certain files are set with different users or groups so they can be edited by the installer at runtime (it’s a long shot but worth checking if you can see that in FileZilla).

If you don’t have a working backup from before this problem started then I suggest you make a backup of the current state just before you start the manual update.

Also it might be worth reaching out to your hosting company and asking if they could download WP and unpack it on the server somewhere that you can access and ensure correct permissions are set, they may also be able to perform a full filesystem backup for you in a quicker way that you may be able to do it yourself.

If the host can unpack WP on the server for you then you would just have to move around some files or folders and it could be a lot faster than manually uploading the individual files over FTP.

Hey @pressgang,

Updates can fail for a large number of different reasons and it is often hard to diagnose the failure due to specific configurations present on each server running the update.

Most commonly I see issues with file permissions causing this. Usually a user mismatch caused by the server user being different to the FTP user and both not being present in each other’s usergroup (generally meaning 1 of the users – usually the server user – is unable to update or overwrite files owned by the FTP user). That is a common issue I see when WordPress has been installed by a hosting providers 1-click option in their hosting panel.

If permissions is not the problem here I seen some other things trigger a fail on update for me in the past. An IO hang – if the server the site is on has a moment where it is either overloaded or your system needs to wait a long time for a different system’s IO to complete on the hard disk then the PHP process may time out and be killed by the server (very common on shared hosting systems).

Another thing I have seen cause a problem is that when files are being validity checked and they fail due to a corrupted bit it can halt the installation by breaking the flow with a malformed character or not properly closing a connection it has open resulting in a blocking thread hanging until some of the defensive code in the server realises it’s blocked and decided to recycle the process.

There are many more reasons that things could have failed. It’s easy to speculate what MIGHT cause the issue but a lot harder to say definitively it SURELY caused the problem. It’s especially hard to diagnose the reason without full access to server logs and to have logging levels on their absolute maximum (which can be a slowdown in production setups and is usually not enabled at hosting companies).

My specific theory here as to why your updates failed on 2 different sites at the same point is that it’s caused by permissions issues. An installer can create the files with 1 set of permissions and have different set of default permissions on the directories. I suspect that the directory permissions allowed it to add a new file to the folder as server user but it does not allow that server user to delete files as they are possibly owned by a different user or part of a different usergroup.

What I suggest is that you perform a manual update over FTP on 1 of the sites and see if it can fix it. If it does then I would look more closely at the permissions and what user owns each file and each directory. You can likely use 1 manual update to isolate the issue, perform steps to fix it on the other instances and then with some luck you could perform the updates on all the additional sites using the autoupdater system.

Hey Tammie, I’ve been following at GitHub and in Slack and have been happy to see progress with some of my concerns. Block storage is a bit different than it was when I first tested Gutenberg (still concerns but not quite so bad).

I’m uncertain I could edit my review here into a single good, coherent, issue for the repo but I’ll be sure to do better to voice my concerns in the places where it would be more relevant ??

Confirming this issue that the rel="nobox" attribute did not prevent the plugin from showing the lightbox for images I tagged with it.

Also confirming that Troll’s fix of adding an or condition looking for it to the regex pattern at line 190 fixes the issue.

Thanks Troll ??

UPDATE: Issue resolved, seemed to be a caching related issue where memcache server wasn’t properly cleared after updating WP core to 4.0 resulting in it using a mix of 3.9 core files alongside the new 4.0 ones.

Hey Eric! lol

Thanks for the brilliant advice you gave him, cogdog! Very detailed ??

Also I checked out the site you linked and noticed an alignment issue when using chrome. Near the bottom of the page is a slider (EXPLORE A FEW MIDEA MEMBER ORGANIZATIONS… section). It’s inside a container class of .app but it’s misaligned – no padding to the left side – however other containers use that class so I added a 2nd class to the div and styled it with padding-left:20px and that sorts it out. I know it’s a 2 year old site you might not really use anymore but it’s such an easy fix and I know it would bug me if it were my site lol

I can’t say I’ve noticed the same error on any of the smaller photos I have on my site, but I haven’t checked them all.

Just out of curiosity what do you use to resize your images on upload?

Anyhow if you want to use Jetpack without getting the thumbnail problem then you can simply disable the photon module of Jetpack by clicking on it in the dashboard and then selecting ‘deactivate’.

This is related to the photon module of Jetpack and I am seeing similar issues with NextGen and even the standard built in gallery and individual images. For me it seems to be when the images have a high resolution (over 1000px wide) are your images large too?

It’s most likely because you are displaying the likes of your domain and not the likes of the FB page but I might be wrong.

Upon looking at your site I can say that you are showing the ‘likes’ of the individual URL being viewed and not the ‘likes’ of your FB page.

To include a link to ‘like’ your FB page would require a different plugin. Consider using the official Facebook plugin for that.

Regards
Will