webrightnow

Don’t waste your time here, the developers have stopped supporting this plugin.

Hi, can I just say: this same question has been asked several times in different topics. Each time instead of making the solution public, the developers are initiating private conversations with the users and presumably resolving the issue by email. This is not how support forums work. If there is a solution, please make it public so that I (and everyone else who is looking) can apply it without having to start a new thread. It saves everyone’s time. Or if there isn’t a solution, please say so.

• This reply was modified 7 years, 11 months ago by webrightnow.
• This reply was modified 7 years, 11 months ago by webrightnow.
• This reply was modified 7 years, 11 months ago by webrightnow.

Mmmmh… I don’t want to get into a long dispute here. James, I went through those previous posts, the problem is: they are all marked as either closed or resolved, when in my view they are not resolved at all. At best, the two opposing sides just agreed to disagree on whether it poses a security issue. In my view it does. You can’t just put it to bed by saying: use a strong password. You are talking about educating the whole world about security standards. It would be great if everyone who uses WordPress always adhered to these standards, but the reality is different. Users will chose passwords they can remember. Even when I personally create users and give them strong passwords, I later find that they changed them to something more memorable.
WP is one of the most user-friendly CMSs out there, this is why so many developers build websites on it and so many inexperienced users have access to a WP backend. And this is why the WP team needs to take every possible step to maximize security out of the box, without expecting users to make database changes (as one of those posts suggested!) or install extra plugins. Hiding usernames may not be the ultimate security measure, but it would be a small step in the right direction.
To be honest, it seems to me like WP developers are too proud to admit that there’s an issue there. They have insisted so many times and in so many posts that there isn’t, maybe they worry about losing face if they go back on this and change it. Personally I don’t see what the big issue is: make the necessary changes so the next update swaps usernames with nicknames throughout the frontend, whenever users have chosen this option in the backend.
If that happens, I – for one – promise not to come back here and say: “I told you so”.
??

Sorry, but I have to disagree with your statement that revealing WP usernames isn’t a security risk. Hacking a WordPress site is in no way comparable to hacking into a Facebook account. WordPress hackers can inject a website with malicious script for the purpose of spamming a phishing – none of which can be done via social media platforms.
You are right, a username isn’t a master key – just half of one. You then need a password, which bots can guess at – limitless times if no security plugin has been installed. If the password isn’t strong enough, it will eventually be cracked. You don’t need to tell me about security measures, strong passwords etc. I know all that, I’ve learned it the hard way by developing countless WP sites and seeing many of them hacked, because by default (without added plugins) WP’s security is woefully inadequate.
I think you are missing the main point here: you and I may know how to make a site secure – but the average developer out there probably doesn’t. Whether or not you decide to agree with this fact, it is a fact nonetheless. WordPress is known for being a user-friendly platform that virtually anyone with a minimum level of IT knowledge can use to build a website – and thousands of people do on a daily basis. As a consequence, the web is now littered with millions on vulnerable sites, many of them already hacked and used for malicious purposes. Feel free to check the stats on this, they paint a very clear picture.
Who are you going to blame? Inexperienced developers? Go right ahead, it won’t change the fact that it’s happening.
The posts you linked to are only useful if you already know about the issue. Most people don’t, so the security measures described there are only implemented by a small percentage of developers. The rest of the world is still at risk.
Exposing usernames IS a security risk – fact. The sooner WP developers start taking responsibility for the weaknesses within their system, the sooner we’ll start to see a reduction in spam and phishing sites across the web.
I also made a point about privacy which I think is fundamental: if a user chooses to be known by their nickname, they expect that to be the case for the whole frontend, URLs included. Again, you may argue that there are ways around the issue – but my point is that most people don’t know or understand about all this. The world’s most popular CMS needs to be a lot better at providing security and privacy OUT OF THE BOX, without expecting users to know how to achieve it by way of extra plugins and code changes.

So sorry, I just found a previous post where the issue is already resolved. Thanks for the great plugin!

Hi, I need a bot of help with this.

I did ‘hide_empty’=’no’ in the shortcode, but the empty categories are still not showing.

Also how do I modify the shortcode to show the categories in my custom Woocommerce order instead of by name?

Thanks

Yes, working. Brilliant, thanks!

Problem solved, the theme was loading its own jquery.min.js which was conflicting with the plugin.

Ah, the shortcode doesn’t seem to work even if I add it directly to the page content:

[pjc_slideshow slide_type=”homepage”]

Nothing shows up.

I’ll try to work out why, maybe the theme.

Sorry, I can’t get this to work.

I created a custom page template in my theme and added this line:

<?php echo do_shortcode(‘[pjc_slideshow slide_type=”homepage”]’); ?>

I switch the homepage to use this template. The slideshow doesn’t show in the frontend.

Do I need to somehow enable shortcodes in my custom theme?

Thanks

Oh, actually the error is only on the homepage and it also goes away if I disable Fluid Responsive Slideshow plugin. Maybe a conflict?

Hi, I tried doing that and the fonts are fixed, but now I’m getting a fatal error in frontend:

Fatal error: Cannot redeclare get_plugin_data() (previously declared in /home/winenapkin/public_html/wp-admin/includes/plugin.php:72) in /home/winenapkin/public_html/dev/wp-admin/includes/plugin.php on line 68

If I disable the plugin, the error goes away.

Any idea?

Ok so how do we update? I’m not getting update option in backend.

Thanks

Well, I tried disabling the rule in mod_security and the lightbox seems to be working. Just hope this doesn’t somehow compromise security.

I checked the mod_security logs. The block is caused by this:

Multiple URL encoding detected

SecRule ARGS “\%((?!$|\W)|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})” “phase:request, rev:’2′, ver:’OWASP_CRS/3.0.0′, maturity:’6′, accuracy:’8′, t:none, block, msg:’Multiple URL Encoding Detected’, id:’950109′, tag:’application-multi’, tag:’language-multi’, tag:’platform-multi’, tag:’attack-protocol’, tag:’OWASP_CRS/PROTOCOL_VIOLATION/EVASION’, severity:’WARNING’, setvar:’tx.msg=%{rule.msg}’, setvar:tx.anomaly_score=+%{tx.warning_anomaly_score}, setvar:tx.%{rule.id}-OWASP_CRS/PROTOCOL_VIOLATION/EVASION-%{matched_var_name}=%{matched_var}”

Any idea?