bcworkz

Forum Replies Created

Viewing 15 replies - 16 through 30 (of 28,300 total)
  • Moderator bcworkz

    (@bcworkz)

    Nearly anything is possible with WP if you’re willing to custom code something. Do you want this file listing to appear in the front end or back end?

    For a back end list, you can add an admin menu item. The callback passed to add_menu_page() can output any sort of content you like. You can use PHP’s scandir() to get an array of files in a particular subdirectory, then use the array to generate the listings you want.

    For a front end page, the solution depends on the type of theme you use (classic or block). Either way, you’d create a custom template file for the purpose. In classic themes, appropriate PHP code can be placed right in the template file. In block themes, create a custom pattern for your PHP code, then include that pattern in your template file.

    Moderator bcworkz

    (@bcworkz)

    Wp-cron tasks aren’t very reliable when they’re run too frequently. Every minute IMO is too frequent. I suggest nothing less than every 10 minutes. There’s no hard and fast limitation, success depends on a number of individual server factors. 10 minutes could still be too frequent in some cases.

    If you absolutely require code to run every minute, I suggest you utilize true server Cron jobs instead of relying on wp-cron.

    Moderator bcworkz

    (@bcworkz)

    The solution depends on what type of theme you use (classic or block) and where you want the banner to appear (page content, widget area, header, footer, etc.)

    Your main challenge is JS code cannot be reliably inserted into WP content, it is likely to become corrupted on output. One way to get around this is to implement everything as a shortcode. You can then add the shortcode to where you want it to appear. Depending on where that is, if it’s not automatically expanded to your embed code, you may need to explicitly expand it with PHP like so:
    <?php echo do_shortcode('[your-shortcode-name]'); ?>

    Moderator bcworkz

    (@bcworkz)

    The error is because $this->posts array does not have an index 0 element. For a single page this element should contain the requested page/post object. You apparently have code somewhere that’s corrupting this array. On your template, I suggest you declare global $wp_query;, then print_r( $wp_query->posts ); at various places in your template code to determine exactly where it gets corrupted. It’ll likely be a function call. You may need to temporarily do something similar within that function’s source code to determine exactly where the array gets corrupted. If this function is a WP core function, the corruption likely occurs at a filter or action hook. Once you know which hook, look for callbacks added to that hook in your code. One of them is the likely suspect.

    Moderator bcworkz

    (@bcworkz)

    Use the phpMyAdmin app (usually accessed through your hosting account) to see what tables actually do exist. It’s possible you have the right tables, but the table prefix (the i8826950_wp1.wp_ part) doesn’t match what you have assigned in wp-config.php. If there’s a mismatch, either rename the tables or alter the value in wp-config.php so everything matches.

    If by chance the tables are truly missing, you’ll need to run the /wp-admin/install.php script again. Rename any WP tables you do have so their data can be exported/imported into the newly installed nearly empty tables.

    Moderator bcworkz

    (@bcworkz)

    Role capability is indeed the intended way to manage access to admin menu items, but how well that works depends on which menu items you want to hide. It’s possible the ones you want to hide require the same capability as ones they must have access to. You can have finer grain control by manipulating the global $menu and $submenu arrays for certain users. Note that manipulating these arrays can remove certain menu items, but if a user knows the URL of the hidden item’s destination, they could still go there and do something you don’t intend to allow. But the lack of a menu item ought to deter all but the most savvy of WP users. Just know that it’s not 100% secure.

    Moderator bcworkz

    (@bcworkz)

    Google scripts belong in the <head> section, not the page’s header. Thus your theme’s header.php template. Assuming where you want the Google code to go in the template is already HTML code and not PHP, you’d implement the PHP logic like this:

    <?php if ( ! is_user_logged_in() ): ?>
   <script>
      // actual Google script goes here
   </script>
<?php endif; ?>

    You could instead filter out data coming from your IP address in your Analytics account.

    Moderator bcworkz

    (@bcworkz)

    That would most likely need to be done when you create or edit the document prior to making the PDF file. In theory it might be possible to do so on the fly as the document is downloaded, but I’m unsure if such an extension is available for WooCommerce. I suggest asking in their dedicated support forum for possible suggestions.

    Moderator bcworkz

    (@bcworkz)

    WordPress in inherently open source, so it’s natural for it to offer alternative sources of blocks that might be available. You’re more after a “walled garden” approach, which is counter to the WP open source concept. A walled garden approach is fine, it’s your site after all, but you’ll need to expect to fight WP a little to accomplish it.

    Contributors and authors don’t see the 3rd party offers. Only those with elevated privileges will be able to utilize the feature. If you don’t trust those with elevated privileges to refrain from doing undesirable things, it’s questionable why they’d be granted elevated privileges to start with. Just sayin’

    Aside from removing user privileges, I’m not sure how easily the feature can be fully removed. However, it is relatively simple to just hide the feature with some custom admin CSS:

    .block-directory-downloadable-blocks-panel {
    display: none;
}

    Those with adequate knowledge and privilege could re-display the feature and utilize it, but being out of sight should deter nearly all users.

    Moderator bcworkz

    (@bcworkz)

    The site icon wouldn’t normally appear on the page editor screen, it’s usually set through general site settings.

    In any case, the favicon appears correctly on your site’s home page when I checked. The file retrieved was: /wp-content/themes/sage/resources/images/favicon/favicon.ico. Proper output of your selected site icon is the responsibility of your theme. If you’re having difficulty with site icons, I recommend seeking assistance through your theme’s dedicated support channel.

    Moderator bcworkz

    (@bcworkz)

    Your shortcode snippet is incomplete. It’s not clear what HTML the shortcode is to output.

    In any case, if you go with Eshaan’s suggestion of <summary> and <detail> elements, it cannot be in a <select><option> dropdown field like you have now. It’s also not a form element so you’d need to send the user selection through different means, which would involve JavaScript.

    To get the behavior you want in the current dropdown field, you’ll need to use JavaScript. I’m not sure how well this would work. It’d be difficult to discern a click that selects a top level element from a click meant to expand the element. And relying on a hover event to expand would not be mobile compatible. I suppose the expansion content could also contain the top level element again so clicking on that would be a selection. Clicking on the unexpanded element would not be a selection but only a request to expand/close the sub-elements. I think this could confuse users. It’s not the most elegant approach, but it’s all I can think of if you stay with a dropdown category list.

    So your shortcode would only output top level elements. You’d install JavaScript listeners on each of the elements. On click, the listener callback would insert the elements that users would click on to select. I’m not sure the browser will immediately display <option> elements added by script. I advise developing a minimal proof of concept test before spending a lot of time developing a full solution.

    Moderator bcworkz

    (@bcworkz)

    OK, but titles and slugs are two different values for the same post. You’ll also need “slug_de” and “slug_en”.

    Moderator bcworkz

    (@bcworkz)

    It’s unclear where your difficulty lies. WP has a built in mechanism to register users. Users can manage most of their user profile themselves. It’s possible to add additional fields to the user profile screen. Look through the source code for /wp-admin/user-edit.php. Look for calls to do_action(). These hooks can be used to output additional HTML input fields. The registration form can similarly be modified.

    It’s even feasible to create completely custom registration and profile edit screens. As along as your forms post data in the same format as the default screens, WP will update user data for you. Or your forms could submit to a custom script which handles updating the DB in any manner you wish.

    Moderator bcworkz

    (@bcworkz)

    I don’t think you have anything hooked to the “post_link” filter yet, so there’s nothing to replace? AFAIK this would be mostly new code, though you could likely borrow certain snippets from elsewhere. You should have meta fields for translated slugs, but it’d be possible to auto-populate the fields for a new post based on translated title input. For de. and en. subdomains you’d need to alter the queries to find the slug in post meta instead of the usual post name. This can be done through the “pre_get_posts” action hook.

    Moderator bcworkz

    (@bcworkz)

    Poedit isn’t sophisticated enough to distinguish from different text domains in plugin files. Expected behavior, though I wouldn’t say it’s “correct” behavior ?? The textdomain property is principally used for organizational purposes and to allow WP to load the correct translation files. Since core translations are always loaded, it doesn’t really matter which you specify, but for consistency I recommend specifying anyway.

    Consider carefully which core translations you use. It’s possible a core string could change in the future, requiring you to update your code accordingly. Some strings are less likely to change than others. I’d stick with the unlikely to change strings.

Viewing 15 replies - 16 through 30 (of 28,300 total)