Forum Replies Created

Viewing 15 replies - 1 through 15 (of 629 total)
  • Plugin Author Gagan Deep Singh

    (@gagan0123)

    @jordantrizz

    To shed more light on the issue, a concern was initially reported to Patchstack about our plugin’s logging functionality. After investigation, we clarified to Patchstack that the logging feature of our plugin, when enabled, does not record sensitive information. Instead, it only logs routine activities like the purging of specific URLs from the cache. This information is standard for operational logs when debugging and does not pose a security risk or contain any sensitive information.

    Also, our plugin requires explicit action from administrator account to activate logging, and by default, it does not generate or expose any data. Furthermore, in our extensive testing with various respected hosting providers, we found that they already have measures in place to block public access to all log files, adding an additional layer of security.

    Based on the detailed information and analysis we provided, Patchstack reassessed the report and concluded that it was not a security issue. Consequently, they have removed the entry from their database.

    We understand the importance of security to our users and assure you that we uphold the highest standards in safeguarding our plugin. Your trust in our commitment to security is invaluable, and we remain dedicated to transparent communication about any such concerns.

    If you have further questions or need more information, please feel free to reach out to us.

    Plugin Author Gagan Deep Singh

    (@gagan0123)

    @dpitzer

    Well, thats what happens when services blindly trust third-party databases and apply caching on top of that.

    Plugin Author Gagan Deep Singh

    (@gagan0123)

    @caordawebsol

    We have confirmed that the concern raised was not a security issue, and at no point was there any compromise to the sites using Nginx Helper.

    Following our detailed communication, Patchstack has re-evaluated the situation and has accordingly removed the entry from their database.

    Therefore, we are marking this ticket as resolved. Thank you for your attention to this matter and notifying us.

    Plugin Author Gagan Deep Singh

    (@gagan0123)

    @pebworthbells

    Thanks for reporting the issue.

    Can you please provide a few things:
    1. WordPress version installed
    2. Theme you’re using
    3. List of plugins installed on your WordPress site (if they have version numbers, that would be really helpful)
    4. Version of Elementor installed on your WordPress site.

    With this detailed information, I will be able to recreate a similar setup to yours to replicate and thoroughly investigate the issue.

    Plugin Author Gagan Deep Singh

    (@gagan0123)

    Apologies for the delayed response.

    While the plugin does enable you to insert shortcodes directly into menus, it doesn’t automatically adapt the shortcode’s output to fit your theme’s menu structure. Therefore, it’s crucial for you to manually wrap the shortcode in the appropriate HTML tags as needed to ensure compatibility when needed.

    You can find a visual guide on how to do this by referring to the following screenshot:
    https://ps.w.org/shortcode-in-menus/assets/screenshot-3.png?rev=1018011

    For a more detailed walkthrough, you can consult this tutorial:

    This tutorial will help you understand how to wrap the shortcode with the necessary HTML tags and classes to achieve the desired appearance and functionality.

    Rest assured, the plugin is actively maintained for compatibility with new WordPress releases. Limited version updates are intentional to avoid feature bloat. I test the plugin with each WordPress release to ensure it remains stable and functional.

    I hope this answers your query and provides ample information to fix the issue on your site.

    @okikam

    Were you able to resolve this issue?

    If yes, I would appreciate it if you could share what worked so that anyone else encountering a similar issue might benefit from this discussion.

    If not, and you’re still experiencing the issue or have additional questions or concerns, please don’t hesitate to ask. I would be happy to assist you further.

    @okikam

    Thank you for the detailed explanation and for taking the time to run through all the troubleshooting steps. This helps a lot in diagnosing the problem.

    No problem about {your_site_url} and {my_site_url}, I already understood its the same.

    The fact that the English site is showing an older snapshot and is missing a couple of posts while the Japanese site appears to be updated and working fine suggests there might be a problem with how the duplicator plugin copied your site. It could be that some files or database entries or files were not copied correctly or completely, causing the issues you’re seeing.

    Can you please try replicating the site again?

    Also can you verify if you’re using any caching plugins on the site? or if there’s any caching mechanism added by the hosting provider for your site?

    There’s one more thing/suggestion, might not be a direct solution, but given your requirements of running a dual-language site, it might be worth considering converting your WordPress installation to a multisite network. In a multisite network, you can have multiple sites, each with their own separate admin, theme, and plugins, but they share a single WordPress installation. This could simplify the management and synchronization of the two sites.

    Here’s a step by step guide to create a network of sites by using the multisite feature.

    @matsumurakenpo

    Thanks for the follow up.

    It’s good to know it finally worked out for you ??

    @dannyogolo

    Since you mentioned that the post type and custom taxonomies are already defined, you can simply make use of the “Query Loop” block on any page.

    Here’s a step by step guide for the same:

    Step 1:

    Create a page

    Step 2:

    Add “Query Loop” block, using any template you like

    Step 3:

    Edit Query Loop block settings to use the Jobs post type(assuming that’s the name of your CPT)

    Step 4:

    In the Filters section of the settings, select Taxonomies

    Step 5:

    Enter the Job Type and Location in those filters and it will display only those Jobs with the given Job Type and Location custom taxonomy terms applied to them.

    That’s its, you can then modify the template as you like.

    For the purpose of these screenshots I created CPT and custom taxonomies using following code ( not that its needed, but just sharing)

    add_action( 'init', function () {
    	register_post_type( 'job', array(
    		'label'        => __( 'Jobs', 'experiments' ),
    		'public'       => true,
    		'show_in_rest' => true,
    	) );
    	register_taxonomy( 'job_type', 'job', array(
    		'label'        => __( 'Job Type', 'experiments' ),
    		'show_in_rest' => true,
    	) );
    	register_taxonomy( 'location', 'job', array(
    		'label'        => __( 'Location', 'experiments' ),
    		'show_in_rest' => true,
    	) );
    } );
    • This reply was modified 1 year, 6 months ago by Gagan Deep Singh. Reason: Highlight Steps

    @kellyirenuma

    This error message suggests that your WordPress site is unable to locate necessary tables in your database. This could occur due to several reasons, such as a misconfiguration in your wp-config.php file, or actual missing tables in your database.

    Here are some steps you can take to troubleshoot:

    1. Check your wp-config.php file: Ensure that the database name, database user, database password, and database host in your wp-config.php file match with your actual database credentials.
    2. Access your database: Use phpMyAdmin or a similar database management tool provided by your hosting provider. This allows you to view and interact with your WordPress database. Check if the database specified in wp-config.php exists and if the tables are there.
    3. Verify table prefix: In your wp-config.php file, check the $table_prefix value. If it’s set to wpts_, your WordPress installation will expect all the core tables to start with wpts_. If they don’t (for example, they start with wp_), you’ll need to change the $table_prefix value to match.
    4. Repair the Database: If the tables do exist but are corrupt, you might need to repair your database. Add
      define('WP_ALLOW_REPAIR', true);
      to your wp-config.php file. Then, visit yoursite.com/wp-admin/maint/repair.php (replace yoursite.com with your actual domain) and follow the instructions to repair and optimize your database.
    5. Restore a Backup: If the tables are missing and you have a recent backup of your website, you may want to consider restoring the backup.

    Any time you’re dealing with your site’s database, you should be very careful. Manipulating the database can potentially result in data loss or broken functionality if not done correctly.

    Always keep a backup.

    Happy to help ??

    @langers2022

    You can follow the Manual Update guide to update WordPress manually. Before that, ensure you take a backup of your entire site in case something breaks.

    @lehren

    Thanks for the follow up ??

    I also tried reaching out to Twitter, but where there used to be contact forms for support, now only article links are there and no form to be found on their contact us page.

    Keeping track of your request on Twitter Developers site

    @henxiaoyi

    Before attaching any file, please ensure it does not contain any credentials. Then you can provide the link to the file here.

    @matsumurakenpo

    Your configs do seem correct, but in .htaccess I’d still add two more lines, one on top and one at end, to check whether the mod_rewrite is even enabled or not

    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    
    # add a trailing slash to /wp-admin
    RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
    
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
    RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
    RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
    RewriteRule . index.php [L]
    
    </IfModule>

    Though, it won’t help in your situation since it’s a redirect loop. Can you please confirm that only code written above is there in .htaccess and not anything else?

    In your wp-config.php file, can you please check if WP_SITEURL or WP_HOME constants are defined? If so, can you please remove or comment those lines?

    If the redirect loop still continues, it means some plugin or theme code might be causing the redirection, and if they are using wp_redirect function, we can temporarily stop those redirects by adding this code in active theme’s functions.php

    add_filter('wp_redirect', '__return_false');

    There are lot more things that can cause the issue, but if you can confirm these three things, we start going through other factors.

    Also, ensure to backup your site and database before making changes.

Viewing 15 replies - 1 through 15 (of 629 total)