psamathe

Any news on this bug?

Many thanks. Will give it a go.

This plugin should really not be used today, there’s almost zero reason to use it, use the browser upload tools or contact your webhost to fix it so that the uploader works for you. 13 years ago when this plugin was written there was a real need, today not so much.

I have found it useful on quite a few occasions travelling South America and SE Asia – where Wi-Fi/Internet is “poor” then put in quite a few guests trying to use it and uploads become difficult. Maybe more to do with the clients than WordPress but I’ve found under those circumstances FTP a more reliable (less likely to fail) mans to upload images.

So useful and appreciated.

I’m not the developer (but am a s/w dev) and I suspect the plug-in developer will need something more than “a part of the coding of the [plug-in]”. After a quick scan I can’t see how “the plugin has gone into my htaccess files” so dev might need to know if it was an issue with htaccess or quite what somebody has identified – most developers would need more detail than “a part of the coding of the [plug-in]”

I’m not the developer but how has the plug-in “gone into my .htaccess files”. I checked on mine and it has not touched my .htaccess file (unless I’m doing something different). A quick scan of the plug-in code and I can’t see any reference to .htaccess.

Without compromising your security (by publicly publishing info best not published), what changes were made to your .htaccess files that caused the issue? (i.e. just the lines added or changed or removed provided they don’t give out info you should keep private).

for comparison: this is a site where file-select-box is still active
https://highlandsmtb.de/htr550/

When I view that page in Safari (Mac) none of the tracks show whatever the state of the visibility boxes. Refresh the page and you briefly see a blue track but that is over-written quickly when the map appears. Click away on the select boxes at the bottom and nothing changes.

Update to Safari 14 makes no difference i.e. same problem in Safari 14

Because of the very different behaviour between e.g. Firefox (works) and Safari (does not work properly) I think this is a bug rather than a feature request.

• This reply was modified 4 years, 2 months ago by psamathe.

To clarify and based on example, using macOS Safari (latest release versions), map box in web page, from html has width=670, height=600 (html being “<canvas width=”1340″ height=”600″ style=”position: absolute; left: 0px; transform-origin: left top; transform: matrix(0.5, 0, 0, 0.5, 0, 0);”></canvas>”. Press the fullscreen button and the “map” html changes to width=1340, height=600, html being “<canvas width=”1340″ height=”600″ style=”position: absolute; left: 0px; transform-origin: left top; transform: matrix(0.5, 0, 0, 0.5, 0, 0);”></canvas>”

HOWEVER, in Firefox it works and you get a proper fullscreen. In the page map box the html “<canvas style=”position: absolute; left: 0px; transform-origin: left top 0px; transform: matrix(0.5, 0, 0, 0.5, 0, 0);” width=”1340″ height=”600″></canvas>”. But in fullscreen mode the html=”<canvas style=”position: absolute; left: 0px; transform-origin: left top 0px; transform: matrix(0.5, 0, 0, 0.5, 0, 0);” width=”3352″ height=”1224″></canvas>” – the height is somewhat different.

So (and I don’t appreciate how or where this fullscreen is being done) it looks like it’s not recognising or handling the Safari browser properly. Maybe a bug in the if(browser==”safari”){ code (I know that’s not PHP nor js!).

NOTE, as it looks macOS Safari based I’m happy to undertake and tests (incl. changes to js/php/css) – but need to be told what to do as I can make minor php/css changes OK but I’m not a web developer (so no js and limited on other aspects – I’m C/C++ dev)

• This reply was modified 4 years, 2 months ago by psamathe.

Sorry but I can’t offer much advice as a lot depends on what you are using (Windows, Mac, iDevice, Android device, etc.). Plus some FTP clients are techy oriented whilst others have lower functionality but are less “techy”.

It is a bit more “techy” in that you’ll have to create directories (normally under wp-content) and work out the relative path to reference the gpx file in the shortcode.

I’m Mac/iDevice based and I use Transmit FTP client (which is pricey and if choosing again now I’d chose something better). Also, Transmit on iDevices is actually no longer available (but is there for people who purchased it before it was discontinued).

Also, FTP clients are a bit like Windows Explorer/macOS Finder – you can delete files as well as upload, copy, etc. and deleting the wrong file can have impacts! etc. and they will give you access to all the WordPress core files, plug-in files, theme files, etc.

I always upload my gpx tracks using FTP client into a directory on the web server NOT through the WordPress Media Library. When I 1st started using OSM (ages ago – it’s so good I’ve stuck with it) I never managed but FTP to a directory is easy and works and I can’t see any benefit from loading the gpx tracks into WordPress Media Library.

One other thing I’ve noticed where you are using a single map showing an extended multi-day trip (multiple gpx tracks): I go on several month long cycle tours. Each day log post has a map for that day (easy, single gpx track) but I also build-up a total trip map which whilst travelling ends-up with more than 60 gpx tracks. This “combined” total trip map can become slow to load – nothing to do with OSM but because it has to open and load more than 60 different gpx tracks. Once home I create a single (larg) gpx track with combines the individual tracks and it all runs much smoother and faster. Not an issue for a few tracks but for longer trips when convenient combining helps – again nothing to do with OSM just that lots of small individual files is slower than one larger combined file.

Many thanks. Sorted.

Many thanks for clarifying (I’m not familiar with all these aspects).

On my plug-in (a few versions behind as I’ve still got to backup, do some upgrades, etc). I’m on 4.0.0-rc13 (so not too far behind).

Just to fully clarify, only option I can find re-kits and accounts is “Use PRO checkbox” (requires a subscription). But my site html includes:

<link rel='stylesheet' id='font-awesome-official-css' href='https://use.fontawesome.com/releases/v5.8.2/css/all.css' type='text/css' media='all' integrity="sha384-xxxxxxx" crossorigin="anonymous"/>

I’ve changed the “integrity=” in this post as I’m unsure about its meaning (or if publishing on open forum is “unwise”

Thanks, but I don’t have a Fontawesome account (using the free account and CDN?). Just installed the plug-in but I’ve no idea how close to the free plan limits my site is running.

So no account to log-into to check use (or to ask Fontawesome about). The generated html does include an “integrity key” but I’ve no idea where that was generated from and assume it is some type of UID.

Or maybe I’m confused – I just installed plug-in and used it (and plug-in correctly removed use by other plug-ins). But I’ve no idea if users might be getting “limit reached” errors from the Free Plan limit or if all is working fine

It’s not causing a massive issue (Digital Ocean are entirely blocked anyway (they are an ongoing hack nuisance) and you are (largely) running on Digital Ocean so included in their block.

I don’t have any of the features you listed enabled. I have in the past (CCSS) but that was disabled over 6 months ago.

Digital Ocean being moved to blocks nearer the “internet” now so they’ll not be clogging-up logs any more with their hackers (do they actually host anybody other than hackers?)

Version 3 was a nightmare. Trashed pretty well all of my settings, kept asking for a seerver key (even though I don’t use any cloud stuff, no image optimisation, no CCSS, etc.).

It’s waiting on your support to have time to run an investigations to what’s wrong. Took me some time to sort out the settings to get my site working again. So not keen on upgrading until the issues are sorted.

The issue here has been going on since before V3 release.