Forum Replies Created

Viewing 15 replies - 1 through 15 (of 19 total)
  • Critical Error (formerly White Screen of Death):

    The WordPress critical error can have a variety of causes, though the issue often can usually be traced back to an issue with PHP: either your memory limit being surpassed, or an error in your code, plugins, or theme. It may also be an issue of database corruption.

    Since the problem can be caused by any number of things, check the error log on your server. If you can’t find the log, please contact your host. Meantime, enable wp_debug and wp_debug_log and after an error, look at wp-content/debug.log to see if anything gets logged there.?

    https://www.ads-software.com/support/article/debugging-in-wordpress/

    Please also review the following article for details on this error and some tips how to fix it:

    Use a membership plugin with booking capabilities. There are add-ons that can be incorporated to the standard membership plugins. Here’s two examples:

    I believe what you are looking for is a new feature that guarantees this kind of block compatibility between theme types (block based or not). New features are requested via trac:

    https://core.trac.www.ads-software.com/

    I’d also recommend you try the Reusable Blocks Extended plugin. It includes multiple functionalities, some of them related to block editing.

    To address your requirements I’m afraid you’d need to modify the behavior of your shortcode so it only executes after the user has made a selection from a dropdown menu. This usually requires some JavaScript to handle the user interaction and AJAX to process the shortcode execution server-side only after the dropdown is changed. You can:

    1. Add a PHP function in functions.php to check if it’s being triggered by an AJAX request.
    2. Add JavaScript to your theme to handle the dropdown change and initiate the AJAX request.
    3. Formatting the output can be managed by another PHP function after the Python script’s output is captured. Use PHP functions like nl2br() (for converting newlines to <br> tags) and esc_html() (to escape HTML entities and ensure security)

    Alternatively, you can use scripts for this, or parts of it. For instance:

    AJAX Load More is a popular plugin that allows you to load posts, pages, comments, and other content with AJAX queries. You can customize it to work with shortcodes and trigger actions based on user inputs such as selections from a dropdown.

    I’d try creating a new javascript .js file in your theme directory and then enqueue it via the functions.php file as described in the official documentation:

    https://developer.www.ads-software.com/themes/basics/including-css-javascript/#scripts

    This way you could extend the block editor using JavaScript to dynamically add styles when a particular template is selected in the template chooser.

    I believe you can achieve this by using the function render_block() (documentation). If you want to manually render blocks within PHP, you need to convert the block markup into rendered HTML.

    Example expanding the code you provided:

    <?php
    // WP_Query arguments
    $args = array(
        'post_type'              => array('post'),
        'posts_per_page'         => -1,
        'order'                  => 'DESC',
        'orderby'                => 'date',
    );
    
    // The Query
    $query = new WP_Query($args);
    
    // The Loop
    if ($query->have_posts()) {
        while ($query->have_posts()) {
            $query->the_post();
    
            // Define your block pattern as a string
            $block_pattern = '<!-- wp:group -->
            <div class="wp-block-group"><!-- wp:post-title /-->
    
            <!-- wp:post-date {"style":{"elements":{"link":{"color":{"text":"var:preset|color|red"}}}},"textColor":"red","fontSize":"small"} /-->
    
            <!-- wp:post-excerpt {"excerptLength":25} /--></div>
            <!-- /wp:group -->';
    
            // Parse the block pattern
            $blocks = parse_blocks($block_pattern);
    
            // Render each block
            foreach ($blocks as $block) {
                echo render_block($block);
            }
        }
        wp_reset_postdata();
    }
    ?>

    The new WordPress feature “Patterns Overrides” is designed specifically for block themes because these themes are built around the WordPress block editor, which integrates closely with the concept of patterns. Not sure how this could be incorporated to classical themes, unless I’m missing something.

    In any case, new feature are submitted via trac. If you can elaborate that requirement properly, with examples and a solid use case, please try a new submission here: https://core.trac.www.ads-software.com/

    I’m glad it worked! If what you want is to remove any trace of the plugin (both from the wp-admin menus and the plugins lists) for non super-admins you can try this one:

    // Function to restrict access to test-plugin settings and hide it from non-super-admin users
    function restrict_and_hide_test_plugin($plugins) {
        // Check if current user is not a super-admin
        if (!is_super_admin()) {
            // Remove the plugin's menu item
            remove_menu_page('test-plugin');
    
            // Optionally, you can also hide the plugin's settings submenu
            remove_submenu_page('test-plugin', 'test-plugin-settings');
    
            // Check if the test-plugin is in the list of plugins
            if (isset($plugins['test-plugin/test-plugin.php'])) {
                // Remove the test-plugin from the list
                unset($plugins['test-plugin/test-plugin.php']);
            }
        }
        return $plugins;
    }
    add_action('admin_menu', 'restrict_and_hide_test_plugin');
    add_filter('all_plugins', 'restrict_and_hide_test_plugin');

    Again, remember to replace test-plugin with the right plugin slug.

    It sounds like there could be several issues at play here, especially since the problem is occurring both locally and on your live site. I would troubleshoot this step by step:

    1. .httaccess – It looks fine, but make sure the file permissions are correct and that there are no extra characters or spaces at the beginning or end of the file. Also, check rules: sometimes, plugins or manual edits can add rules that interfere with WordPress’s default behavior.
    2. Site(s) address: In your WordPress settings, go to Settings > General. Ensure that the WordPress Address (URL) and Site Address (URL) are correctly set to https://thewlstorage.com/ for your live site and https://local-site.local/ for your local site.
    3. Plugin/Theme Conflicts: Try deactivating all plugins and switching to a default WordPress theme like Twenty Twenty-One to see if the issue persists. If the problem resolves after deactivating plugins or switching themes, you can reactivate them one by one to identify the culprit.
    4. Clear Browser Cache, and try again with different browsers and incognito windows.
    5. Check server and provider error logs – Ask your hosting provider if not familiar with this step, for any clues.
    6. Check if any errors are logged in the debug.log file located in your wp-content directory. Any PHP errors or warnings could provide insights into what’s causing the issue.

    It’s hard to debug a very specific issue like this from our own setups, but I hope those steps work and you can identify the source. Please post your findings.

    There are a few potential solutions you can try:

    1. Consider using WP-CLI for media import purposes: https://developer.www.ads-software.com/cli/commands/media/import/
    2. The plugin Add From Server should allow you to import media files that are already uploaded via FTP directly into your media library.
    3. Database Repair: Database inconsistencies or corruption can also cause issues with media files not showing up in the library. WordPress has a built-in database repair feature that you can use to attempt to fix any issues. You can add the following line to your wp-config.php: define('WP_ALLOW_REPAIR', true);
      After adding this line, you can access the repair page by visiting https://yourdomain.com/wp-admin/maint/repair.php. Remember to remove the line from wp-config.php after you’ve finished repairing the database for security reasons.

    There should be a way of doing is with a custom function you could add to the functions.php file of your current theme.

    // Function to restrict access to test-plugin settings
    function restrict_test_plugin_settings() {
        // Check if we are on the plugin's settings page
        if (isset($_GET['page']) && $_GET['page'] === 'test-plugin-settings') {
            // Check if current user is not a super-admin
            if (!is_super_admin()) {
                // Redirect non-super-admin users away from the settings page
                wp_redirect(admin_url());
                exit;
            }
        }
    }
    add_action('admin_init', 'restrict_test_plugin_settings');

    Replace 'test-plugin-settings' with the actual slug of the settings page for the “test-plugin”.

    Related documentation:

    You are describing multiple issues, which makes this debugging a bit more complex. But given the 3 you’ve described, I’d check the following:

    Subdomain Configuration

    First, ensure that your server configuration supports subdomains. For a WordPress multisite with subdomains, you need:

    • DNS Wildcard Records: You must have a wildcard DNS record (*.yourdomain.com) pointing to your server. This allows all subdomains to be routed to your server without having to set up DNS records for each new site.
    • Apache/Nginx Configuration: Your web server (Apache or Nginx) needs to be configured to accept wildcard subdomains. For Apache, ensure your VirtualHost is configured with ServerAlias *.yourdomain.com. For Nginx, you should have server_name yourdomain.com *.yourdomain.com;.

    WordPress Configuration

    • wp-config.php Settings: Verify that your wp-config.php is correctly configured for a multisite. This includes setting define('WP_ALLOW_MULTISITE', true);, define('MULTISITE', true);, define('SUBDOMAIN_INSTALL', true);, define('DOMAIN_CURRENT_SITE', 'yourdomain.com');, and define('PATH_CURRENT_SITE', '/');. Also, make sure you have the correct SITE_ID_CURRENT_SITE and BLOG_ID_CURRENT_SITE values.
    • .htaccess File: For Apache servers, make sure your .htaccess file is correctly configured as per WordPress’s network setup instructions. This file controls the URL rewriting capabilities of WordPress.

    Database

    It appears that some of the necessary tables for your new sites are not being created, which could be due to several reasons:

    • Database User Permissions: Ensure that the database user has all necessary permissions to create and modify tables in the database. This includes SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, and so on.
    • Debugging: You can enable WordPress debugging by adding define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true); to your wp-config.php file to see if any specific errors are being logged.

    I’d recommend the AI Engine plugin. You can connect it to your ChatGPT (or CoPilot or others) account and train it using your own site’s contents.

    Have you checked your spam folder? It might have gone there.

    If still you cannot access the password email, kindly look at the support article below for other options you can use to rest your admin password:

    Hi, I suggest you enable WordPress debugging to see if any errors are being logged to the wp-content/debug.log file. You can do this by adding the following lines to your wp-config.php file:

    define( 'WP_DEBUG', true );
    define( 'WP_DEBUG_LOG', true );

    Also, check your server’s Google VM error logs for any clues. Look for any PHP errors or other relevant messages that might indicate what’s causing the issue.

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