3Lancer

Resolved: An update on this. It’s not a coding issue of the plugin, rather was just due to moving of those css/js file locations, but the pages where still cached. Here, I was hunting through the code but couldn’t find it, when merely clearing the page cache fixed it.

Cheers again for your help “Pioneer Web Design”. Found it!
Under the plugin itself, it registers Posts Taxonomies.

When you register the post type, you can add a parameter:
'has_archive' => false

It was previously on ‘true’ and therefore creating that archive list at that location.

Found it!

For anyone else if interested.

Under file ‘Register_EWD_UFAQ_Posts_Taxonomies.php’, there’s the page args…

'has_archive' => true
change to:
'has_archive' => false

It’s the plugin which is triggering it at least.

Disable the FAQs plugin and the normal WordPress FAQs page appears, rather than the archive list. However, this didn’t occur on another server when testing.

I’ll ask the plugin owner too.

The reason for needing it to be /faqs/ – is that’s also the “FAQ Slug Base” the plugin uses, the pages, categories and tags go under it, you can also add a search box, etc. I would like to keep the same structure as the old plugin too or 1000s of other pages will need to be redirected under it.

Thanks for your response.

Recreating the page didn’t help.

Changing the URL slug made it work fine, for example “/faqs-2/” – But I need that URL “/faqs/” and that was working fine previous… why did it suddenly change? Is there a mark somewhere under the WordPress database for where an archive is placed?

Wordpress shouldn’t be just creating them for the sake of it and give the owner no options to overwrite/remove?

If you know how to modify your own Theme code, you could for now add something like this to your ‘functions.php’ under your theme:

function dequeue_conditional_styles(){
    if( (!strpos($_SERVER["REQUEST_URI"], 'faqs')) ) {
      $removeFAQScript = false;
      if (function_exists( 'is_woocommerce' )) {
         if (!is_woocommerce()) {
            $removeFAQScript = true;
         }
      } else {
         $removeFAQScript = true;
      }
      if ($removeFAQScript) {
         wp_dequeue_style('ewd-ufaq-style');
         wp_dequeue_style('ewd-ufaq-rrssb');
         wp_dequeue_script('ewd-ufaq-js');
         wp_dequeue_script('jquery-ui-core');
      }
      wp_dequeue_script('jquery-effects-core');
      wp_dequeue_script('jquery-ui-autocomplete');
      wp_dequeue_script('jquery-effects-blind');
      wp_dequeue_script('jquery-effects-bounce');
      wp_dequeue_script('jquery-effects-clip');
      wp_dequeue_script('jquery-effects-drop');
      wp_dequeue_script('jquery-effects-explode');
      wp_dequeue_script('jquery-effects-fade');
      wp_dequeue_script('jquery-effects-fold');
      wp_dequeue_script('jquery-effects-highlight');
      wp_dequeue_script('jquery-effects-pulsate');
      wp_dequeue_script('jquery-effects-scale');
      wp_dequeue_script('jquery-effects-shake');
      wp_dequeue_script('jquery-effects-slide');
      wp_dequeue_script('jquery-effects-transfer');
    }
}
add_action( 'wp_enqueue_scripts', 'dequeue_conditional_styles', 20 );

This is basically checking the pages URL doesn’t have ‘faqs’ in it (adjust if your base FAQ URL slug is named something else).

It also checks if the Woocommerce plugin is available, and if so ensures not to remove the main scripts from the Woocommerce products pages (incase you have Ultimate FAQs on them too). The effects are still removed, but you can adjust to your desire. Any issues, tweak or remove it. It’s just a temporary patch for now, but should do the trick.

If you require those scripts such as jQuery UI Core or Effects for other webpage/plugin uses, don’t remove them.

• This reply was modified 7 years, 12 months ago by 3Lancer.
• This reply was modified 7 years, 12 months ago by 3Lancer.

Possible fixes to use…

Removing the parameters (supports all PHP version):
$current_url
replace with…
strtok($current_url,'?')

(or)

$current_url = $_SERVER['REQUEST_URI'];
replace with…
$current_url = parse_url($_SERVER["REQUEST_URI"], PHP_URL_PATH);

(breaking down the parameters and later reapplying them if desired)

• This reply was modified 7 years, 12 months ago by 3Lancer.

When you update the file(s), why don’t you just use the W3 cache Empty option?

Logged in under your WordPress Admin, on any webpage, at the top you have “Performance” with a dropdown list “Empty All Cache” or “Empty Modules > Empty Page Cache”.

Adding version control parameters to JavaScript and/or CSS tends to just slow you down.

If you do want version suffix, try the option under W3 cache called “Prevent caching of objects after settings change” I believe? I haven’t tested it myself but this might be what you are after?

@destac – Thanks for your reply. You are correct.

I was planning to swap WordPress local jQuery with a Google hosted one and async it. However, logically jQuery should be loaded early as possible incase the webpage has document onload using it, etc. It will probably just delay it’s wait longer or run into issues. I’ve moved it back out.

Cheers, solved.

@ov3rfly – Cheers, that seems like a good solution!

Yeah, tested, it doesn’t execute the PHP so you will end up with a CSS file like:

#primary-main-menu li
a{color:<?php echo ot_get_option('menu_opt_link_color');?>;border-color:<?php echo ot_get_option('menu_bottom_border');?>}

I guess I’ll just have to leave that file out?

Hi Ashok,

To answer your question, it would be like this:
<link id="dynamic-style-css" href="/themes/dynamic-style.php" rel="stylesheet" type="text/css" media="all">

Note: It’s called dynamic, but isn’t user set, rather admin set only (so doesn’t change and could be cached).

I’m guessing it won’t execute the PHP code to grab the variables, before making it into the CSS file however?

@julien Liabeuf – No worries, just letting you know, in case others bumped into it too. Nothing major. Have a workaround for now. Cheers for your support/patches on this great plugin.

Is anyone else able to test/confirm this minor bug still remaining?

Awesome Support: E-Mail Support (used version 0.2.1, also renewed my subscription and updated to the latest 0.2.2, however same result).

On an admin account, under the WordPress plugin page, click on the “Settings” link on the “Awesome Support: E-Mail Support” plugin.

It leads to: wp-admin/edit.php?post_type=ticket&page=settings&tab=email_support

However displays:
“You do not have sufficient permissions to access this page.”

Yet, if I go under Tickets > Settings > E-Mail Piping, I can access the settings page that way.

It leads to: wp-admin/edit.php?post_type=ticket&page=wpas-settings&tab=email_support

Note: The page name is “wpas-settings” rather than “settings”. This might just be a matter of missing a renaming of the URL parameter?