Forum Replies Created

Viewing 15 replies - 241 through 255 (of 3,596 total)
  • I’ll respond again in a few minutes, but I wanted to say that the most likely problem, in my opinion, is a WordPress plugin that does Caching. As I said in my previous post, even some security plugins default to doing Caching. Usually, the Cache has to be completely flushed after changing any My Private Site settings.

    I’m a little confused by what you have said:

    • “when I go to my site home page, no login is required”
    • “Is my exemption of my home page the problem which is negating a login?”

    If you have a checkmark in the “Site Home is visible to everyone?” field, you will never see a Login or Registration prompt on your site home page. You can, of course, add a Login link to a sidebar using a Widget.

    Caching is the most likely cause of Pages and Posts being displayed that are not set as Visible Exclusions in My Private Site. I’ll get to Caching in a minute.

    I’m not aware of the plugin ever being tested with Content Protector, so I would recommend momentarily deactivating Content Protector while testing My Private Site. They may indeed clash. My Private Site should do the job for you without Content Protector.

    As for what is protected from viewing, My Private Site requires login to view anything that WordPress delivers to a visitor. Examples of things that WordPress does not deliver are mentioned on the Description page in the Plugin Directory:

    This plugin does not control non-WordPress web pages, such as .html and .php files created by hand or by other software products. Or images and other media and text files directly accessed by their URL, or from a browser’s directory view, if available.

    As promised: Caching. Your web browser caches based on URL. WordPress has plugins that cache WordPress-delivered content; some plugins don’t explicitly or obviously say that they cache, including some security plugins that I have seen.

    Caching can give you a Time Machine effect. Showing you a Page or Post as it was at some time in the past, before My Private Site began protecting your web site. Instead of prompting you for a login, you may see the Page or Post delivered to you from a Cache.

    Finally, this is not official support; David provides that.

    Have a look at this thread:
    https://wordpress.org/support/topic/wp-editor-is-showing-blank-white-page?replies=4

    It covers the advice that I would give to you, in better detail.

    A detailed explanation of how WordPress handles so-called “automatic logout” is provided here: https://wordpress.org/plugins/jonradio-remember-me/

    The plugin described there was written as a potential add-on for the Private Site plugin. David also supports it.

    The place to start is at the end of /plugins/jonradio-multiple-themes/jonradio-multiple-themes.php

    if ( is_admin() ) {
    		/*	&& isset( $_GET['page'] ) && ( 'jr_mt_settings' === $_GET['page'] )
    			should work, but redirects Save Changes to options.php
    		*/
    		require_once( jr_mt_path() . 'includes/admin-functions.php' );
    		/*	Admin panel
    		*/
    		require_once( jr_mt_path() . 'includes/admin.php' );
    	} else {
    		require_once( jr_mt_path() . 'includes/select-theme.php' );
    	}

    The require_once( jr_mt_path() . 'includes/select-theme.php' ); needs be run even if is_admin() is TRUE. Be warned: that may cause other major issues. I just don’t know. And I’m afraid that I’m in no position to do the necessary testing and debugging, due to family health issues.

    David provides official support, but it may help to mention that, when I last looked at the code a year ago, the current version of Multiple Themes, Version 7.1, has a bug that effectively nullifies the AJAX functionality. The code built to handle AJAX is not getting executed because it is bypassed for Admin Panels, checked via the is_admin() function. AJAX “appears to be” an Admin Panel as AJAX runs from a /wp-admin/ URL.

    The end result is that AJAX is always executed for the Active Theme.

    Again, I’m going from memory, so I may be wrong.

    Hope that helps.

    Only suggestion that comes to mind is to put all of your custom functions in your Active Theme’s functions.php and sort out any duplication by detecting the theme, e.g. – checking the theme= query of the URL. Clumsy, yes, but it might be a workaround for now.

    I cannot find confirmation, but this blog page indicates that UppSite no longer offers this service:
    https://www.quora.com/With-UppSite-closing-down-whats-the-best-alternative-for-turning-my-WordPress-blog-into-an-app

    Others will have more experience with this than I do. Best I could find in my rudimentary research was this article:
    https://jkwl.io/php/regex/2015/05/18/url-validation-php-regex.html

    Hopefully, someone will have a more helpful answer.

    To answer your question precisely: “Note that the function will only find ASCII URLs to be valid; internationalized domain names (containing non-ASCII characters) will fail.” ref. – http://php.net/manual/en/filter.filters.validate.php

    Is there another way to do that? Probably. Let me look around and respond here soon.

    Forum: Fixing WordPress
    In reply to: Changing Fonts

    You’ll need someone with expertise in that Theme, and they are found here:
    https://wordpress.org/support/theme/solon
    where I suggest you re-post your question.

    As you can see, line 87 only specifies two parameters, and line 335 specifies that 3 or 4 parameters are required.

    As I said, the 8press theme author is responsible for fixing the code in the 8press theme.

    But, that being said, some plugin and theme authors do not know or care about warning messages.

    That would be up to the 8press Theme Author to correct, based on the “\themes\8press\functions.php” part of the warning message.

    On the off chance that you don’t know this, Warning messages are suppressed by setting WP_DEBUG to FALSE in the wp-config.php file.

    Plugin Author jon

    (@adiant)

    It would also be good to eliminate the issues mentioned in this post and the blog it points to: https://wordpress.org/support/topic/shortcodes-may-have-some-new-placement-limitations

    In other words, if you haven’t already done so, please test the simplest possible footer, e.g. – perhaps just [y] and nothing else.

    Plugin Author jon

    (@adiant)

    I actually wrote both plugins, but am no longer able to support them, so David stepped up and adopted them. Shortcodes Anywhere or Everywhere was originally a Work in Progress. I kept looking for WordPress “Hooks” that would cover all the territory where Shortcodes might be used, but I never delved into how different themes are written nor knew much about widgets.

    In other words, I suspect you did everything right, but the plugin just doesn’t have the hook that the theme involved uses.

    All that I can think of is somehow placing the standard WordPress Text Widget in the Footer, which admittedly may not be possible with your Theme.

    Plugin Author jon

    (@adiant)

    I’m back in the office now for the next hour and a half.

    Yes, the testing I described in my first post was done with 4.5.2 from a fresh WordPress install on Sunday and install of the plugins this morning.

    I cannot emphasize enough the value of testing with all the Where? checkboxes checked in the Settings of Shortcodes Anywhere or Everywhere.

Viewing 15 replies - 241 through 255 (of 3,596 total)