dirkmittler

I should explain how this situation arose.

For some strange reason, and, in breach of several rules, the Debian Repositories used to offer an Akismet version, that was bundled with the package-manager installed version of WordPress, and, as if Debian Maintainers did not know at the time, that Akismet requires a paid subscription to use.

I have a Debian-installed WordPress version, which I modded, to be able to accept plugins from www.ads-software.com.

www.ads-software.com’s plugins repository used to offer me Akismet versions that were higher, than what the package manager offered, and I upgraded to the higher versions.

But, it used to be, that every time Debian / Jessie received an update to WordPress via the package manager, this would also downgrade my Akismet version.

This never caused me any problems before, because immediately after a Debian downgrade, my WordPress blogging engine just offered me the upgrade to the latest Akismet version again, so that the downgrade was quite brief.

However, at some point in time, I was not reminded to re-upgrade Akismet, because at some point in time, the latest version was no longer compatible with WordPress 4.1 . Hence, I lost track of these downgrades and/ or upgrades at some point in time.

In any case, I’m on Akismet version 4.0.8 presently, and am under the impression that this is also the best version for WordPress 4.1 .

Dirk

No Harm Done ! ??

Dirk

Conclusion:

Because I’m also using an aggressive caching plug-in, I next decided to switch the method by which ‘PVC’ works, from PHP to JavaScript. And within a few minutes, PVC started to count 4 Post Views! ??

The mystery which is left unanswered by this would be, why then, ‘Post Views Counter’ was reporting views accurately, until the 9th of February, when its setting was to use PHP, with the caching plug-in working.

Now, I’ll just have to settle for a statistically-weaker count next to each posting, because many people have their browsers set to block scripts. ??

Dirk

Follow-Up:

I just did an experiment, in which I left my LAN – which is hosting my blog – and accessed the blog from outside, from the WAN, using my smart-phone browser. I made it a point, to access one posting specifically, which is usually what I have PVC set up to isolate and count. This also means that my IP-address at the time was a public one, which was not black-listed by me, as opposed to IP-addresses on my LAN, which are blacklisted.

The result was, that my smart-phone was able to view that posting by itself, without error, but that even an hour later, Post Views Counter is still showing me zero views.

This seems to confirm that there is a problem in how PVC is operating right now, and not, with nobody visiting my postings. At least one person – me – has since visited a posting of mine.

I should add, the observation that in the line of the server-log which I gave as an example above, the fact that the referrer-URL was a Comment-URL, has little meaning on my blog, because I tend to use such comments as cross-links between my postings. Every time I link to one of my own postings, from another posting, I have ping-back enabled, so that a Comment is also generated. Hence, a Human can easily be clicking on a Comment-Link first, and then retrieving the Posting linked-to from there.

And this was the entry in my server-log, of me doing so:

184.151.111.223 - - [11/Feb/2018:13:43:00 -0500] "GET /blog/archives/4739 HTTP/1.1" 200 11882 "https://dirkmittler.homeip.net/blog/" "Mozilla/5.0 (Linux; Android 7.0; SM-G920W8 Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.137 Mobile Safari/537.36"

Dirk

• This reply was modified 6 years, 9 months ago by dirkmittler.
• This reply was modified 6 years, 9 months ago by dirkmittler.
• This reply was modified 6 years, 9 months ago by dirkmittler.

According to the WordPres.org site, this function was introduced in version 4.3:

Function Reference

Because of that, it does not make sense to indicate that your plug-in will work, as of WP-version 4.0, nor on my version 4.1…

So the actual bug is, that your users need WordPress v4.3 , in order to use the latest versions of your plug-in.

Dirk

Hi.

I was the person who started this posting.

I have a vague suspicion that this issue is due, to how the Debain package-manager-installed version of WordPress, may be coded differently from the public PHP-Files we could just upload to a server.

More specifically it would have to do with the fact that Debian Package Maintainers will either include a core functionality, and then make whichever libraries it depends on a necessary dependency, for installing the main package – i.e.,

php5-gd

Or, how they would otherwise just not put code into the core application, that tries to connect with such a library.

I’ve read in several places that what we need, to get this crop-preview to show properly, is actually

php5-imagick

And, because that’s not an explicit dependency, the core application will omit any codes that would try to use it. But that’s just my guess.

What I have found, is that there’s another way to edit images within WordPress, and that is, to click on the image in our visual editing panel, where we have inserted the image into our posting. When we do that, some buttons appear, including an Edit button – stylized as a pencil. And everything that gets accessed via that editing button – works! ?? This includes, to choose one of the image-sizes, that php5-gd automatically created for us, as well as how to justify the image and several other options. It still does not include a crop feature.

And so, I cannot believe there is anything seriously wrong with my WordPress installation. I just can’t crop.

Dirk

It seems that at first, I did not understand how this editor is supposed to work.

As I now think I understand it, we first need to go to the Web-site, to perform a desktop-install of the actual editing application, and Then, the embedded editor will work.

Considering that by now, I have visited the site, and found that the desktop application at least runs, this ‘makes sense’, because there would have been no real way, in which a few lines of PHP code would have possessed such powers, by themselves.

Further, I see that Vectr is very much a cloud-based product.

While I see no deficiencies in the quality of the product, this just amounts to too-unorthodox-a-way, to install software under Linux, where to download binary blobs is frowned upon. Under Linux, software is supposed to come either from the package-manager, or from a custom-compile of open-source code. Additionally, I have a wealth of graphics-editing software already installed on my desktop machines.

I wish all the Vectr users happy Computing. ??

Dirk

By now I have switched to using a different plug-in, to hide my orphaned short-codes.

Therefore, wanted square brackets now appear correctly on my blog.

Thank you anyway,
Dirk

Sorry to bump.

But I think that an important detail which I just left out above, is that I frequently need for square-brackets to appear in code-blocks, where the conventions of using ASCII-codes 91 and 93 doesn’t work – they’re displayed literally then.

Dirk

This problem was due to a conflict with another plugin, namely, with the ‘Transposh’ translation plugin.

It was mainly inattentiveness on my part, which prevented me from discovering this problem until recently. Another reason for which I had not discovered it, was the fact that it never became obvious in my Editing View, not even in the fancy WYSIWYG panel, because no assumption existed that the default-language version of what I was writing there, should be submitted for translation.

And just today, when I discovered this malfunction, I had tried to remedy it with your plugin, which was unable to do so.

Your plugin works fine, and can make my code-blocks look much fancier than they would have looked before, on the assumption that anybody had been able to read them before. ??

Dirk

I’m sorry to bump this posting again.

But in the file

/usr/share/wordpress/wp-admin/admin-ajax.php

There is code which looks like this:

if ( is_user_logged_in() ) {
/**
* Fires authenticated AJAX actions for logged-in users.
*
* The dynamic portion of the hook name, $_REQUEST['action'],
* refers to the name of the AJAX action callback being fired.
*
* @since 2.1.0
*/
do_action( ‘wp_ajax_’ . $_REQUEST[‘action’] );
} else {
/**
* Fires non-authenticated AJAX actions for logged-out users.
*
* The dynamic portion of the hook name, $_REQUEST['action'],
* refers to the name of the AJAX action callback being fired.
*
* @since 2.8.0
*/
do_action( ‘wp_ajax_nopriv_’ . $_REQUEST[‘action’] );
}

I suppose that a valid question to ask might be, how does an AJAX request know that the client is logged in, since ‘imgedit-preview’ clearly requires this? And the answer seems to be that the AJAX GET request has code that goes like this:

/blog/wp-admin/admin-ajax.php?action=imgedit-preview&_ajax_nonce=

Where the ‘_ajax_nonce’ parameter is a log-in cookie. If something was preventing WordPress from recognizing this, it could prevent the action from firing. But the action produces no errors in the error log, returns with Code 200, but returns Numeral 0.

Dirk

Sorry.

The action ‘imgedit-preview’ is included in ‘$core_actions_get’.

Dirk

Thank you so much for every effort.

I have now received the receipt as well as the download link, and everything works as it should.

There is another detail which needs to be explained, in order for people to use it.

What I am used to, as some other people might be, is that when we upgrade to the Pro version of a plugin, we may have to deactivate the plain version.

In your case, I need to have both the Custom Scrollbar, and the Custom Scrollbar Pro plugins activated, in order to use the extended features, and to have one menu entry appear in my Dashboard.

Dirk

• This reply was modified 7 years, 9 months ago by dirkmittler.

Unfortunately, the only email of that sort which I did receive, was the PayPal transaction receipt.

None of my spam folders contain any email from you. But I do have the transaction ID:

https://www.paypal.com/ca/cgi-bin/webscr?cmd=_view-a-trans&id=9DN37942XH213362W

I am still hopeful that this will get sorted out.
Dirk

Sorry to post to my own thread again.

As it turns out, there was more of a substantial reason, why I was not able to get the iframe to scroll horizontally.

First of all, it was an httpS: URL. Therefore, such CSS options as white-space: nowrap become meaningless, as well as perhaps others.

Secondly, this embedded URL originated as a server-script, that was meant to be embedded, but that was also running much JavaScript of its own, designed to detect the size of the window being displayed in. Thus, no sooner had new dimensions been applied to the window, as the Scripts would reformat the HTML.

Thirdly, I had script-blockers running, which prevented those scripts from doing their jobs properly, and updating the actual content of the iframe.

I’m sure by now that if that iframe had just consisted of static HTML, it could also very easily have received a horizontal scrollbar.

Further, I still hope that this plugin will be useful to me at some time in the future.

Dirk