zimmi88

For theme-based localization, look at the files in wp-content/themes/<your_theme_name>. That directory contains the various template files for a given theme. Plugins are located in wp-content/plugins.

It could be your theme’s author has conveniently set up a language or constants file that you can easily modify. If so, then you can localize those strings. If not, you’ll need to go file by file and search for the strings you want to replace.

Be careful only to replace outputted strings, not function names or internal constants. To be on the safe side, you might want to do this work in a copied version of your theme.

You’ll also need to run your own localization support on version updates to the theme, as any updates have a good chance of overwriting any localization changes.

I hope this helps!

If the first operator of comments_template() is left blank, it’ll assume you have a template file named comments.php, else it will fall back to an emergency template in wp-includes/theme-compat. I’d look first at comments.php for theme-related issues.

Alternatively, I’d recommend checking the posts in question and your settings to see if post comments are being disabled by default. It could be your theme is coded to not display any comment section whatsoever if comments are disabled and there are none to display.

I hope this helps!

Try here to start: https://codex.www.ads-software.com/WordPress_in_Your_Language#Swedish_-_Svenska_.28sv_SE.29. That page has information on community-led efforts to provide WordPress core translations for Swedish (and other languages, for that matter).

Many times, translations are handled by creating translation files, uploading it to wp-content/languages, and setting a configuration variable in wp-config.php. The page also has references to plugins that can enable multi-language support on your site.

That said, it’s worth noting that if you’re using a theme or plugin with english words coded into the source, as can often be the case with breadcrumbs, you’ll likely need to go through the source and translate where necessary. Language files will usually only translate string defaults and admin text provided by core.

I hope this helps!

Hmm… what do you mean by “odd content”? What I can think of off the top of my head is that there might be some usage of template tags or some inner loop that’s messing with the $post variable.

The constructor will return an instance of WP_Query, so you’d want to run array_reverse on $home_shows->posts, not $home_shows itself. You can try checking the result of this by running print_r on the variable after reversing it (you can echo its output into some sort of temporary absolute-placed div just to view the results).

Other than that, the logic seems pretty sound by running the query then reversing the results. From there, you can use the examples from the WP_Query page to run an inner loop.

If you’re still having troubles finding the issue, if you could post back your output code, it might help with figuring out the issue.

I hope this helps!

Hmm… I see a couple ways you could go about this…

• Create a custom theme for WordPress that looks exactly like your current site’s theme. If your site is already set up to use some sort of template system, this’ll be much simpler to do… you’ll just need to copy your templates to a new folder within wp-content/themes and WordPress-ify them. With this method, you’ll get close visual integration with your existing site. If you want to in the future, you can also put your whole site under control of WordPress.
• If every page needs to be on one particular URL, you can either embed using an iframe (using a really light custom theme) or use lower-level WordPress functions to roll your own WordPress front-end. Your custom interface would essentially need to take over the querying and processing tasks that the WordPress core usually handles on its pages. Admittedly, I’ve never really used WordPress functions on pages that aren’t under control of WordPress (as shown using the wp-blog-header.php include), but it makes sense.

I hope this helps!

It’s not the current path that’s the issue… it’s the fact that none of the URLs for any images you added to your posts would have been updated during the migration from directory to directory.

When you add an image to a page or post, the image is included as a sort of reference: a source (SRC) URL is given that points to the image’s location. When WordPress is moved from directory to directory, the image files move, but these pointers don’t change. Hence, files not found.

Put another way, it’s as if someone at the local library moved the photo books over to another wing but didn’t change around all the directional signs. Everyone would go looking in the old location for the books, but wouldn’t find what they were looking for.

An example from the HTML for https://moretonbay.biz/bay-islands-history (shortened)
<div id="attachment_1662" {...}><img {...} src="https://www.moretonbay.biz/wp/wp-content/uploads/2012/01/Coochie-on-the-beach-with-Victoria-point-in-the-background.jpg" {...}></a><p class="wp-caption-text">Coochie on the beach with Victoria point in the background. Courtesy State Library QLD.</p></div>

Note in the above example the SRC attribute, which is pointing to the old directory. These are the URLs you’re going to want to change by removing the “/wp” portion from the file path. Because most of your images are going to be following the same pattern, you can probably use the aforementioned plugin to do a find-replace on the post/page content of every post/page (I’d try searching for src=”https://www.moretonbay.biz/wp/&#8221;, replacing with “https://www.moretonbay.biz/&#8221;).

I hope this helps!

Moving the site usually won’t update the image references embedded in posts, I’m afraid. So, the image references embedded in your posts are pointing to where the images used to be, rather than where they are now.

I’m imagining there’s a number of solutions to this issue you could try…

• Go through each and every post and manually update the image URLs to reflect the new site structure (blech!)
• Add an .htaccess rule that points references for the old URL to the new URL, assuming they’re on the same server.
• Use a plugin or write a script that can go through your database records and find-replace old URL references with the new ones. You’ll want to test this in a sandbox first before using this on your production server. (Related forum post: https://www.ads-software.com/support/topic/how-do-i-change-image-urls-after-site-migration?replies=5)

That said, I can’t say I have much experience with the latter two. The one time I’ve run into this issue, the number of images were relatively low, so manually going through posts was trivial.

I hope this helps!

Well, it looks like whatever theme-specific implementation of previous_post_link that you’re using calls the same function for getting an adjacent post, so unless that function has another parameter for specifying whether to get the previous post or next post, I’m not sure how it would be distinguishing between previous and next post. I’d take a look further at the theme_get_adjacent_post_link method and see if there’s any missing parameters or some other way to distinguish between a previous post and next post. If not, you can try falling back to the methods that are built in to WordPress.

Check out the template tag previous_post_link(). The third parameter in the set allows you to specify whether the previous post that it links to should be from the same category – set to true to enable this feature. A similar tag exists for next post as well.

I hope this helps!

One of the technologies WordPress uses to run is MySQL, a database system. Broadly speaking, a database is a giant collection of organized data, which, in the case of WordPress, it uses to store information about your site, like posts, comments, settings, users, et cetera.

That error likely means the plugin you activated had some MySQL queries (commands to save or retrieve data from a database) it tried to run but was unable to… there was an error in how the query was written such that the MySQL engine was unable to understand what it was saying.

As for the plugin… well, if it appears to be working as expected, awesome. However, if the plugin is expecting to use a table that, due to this error, may not exist, it might run into issues. If this is the case, I’d recommend disabling it for now and either posting in the appropriate plugin forum to see if anyone else is having this issue or, if the plugin author has included contact info, you can try contacting the plugin author directly to let them know of the issue.

I hope this helps!

Cool… well that’s at least progress in the right direction.

Still might be an issue with the .htaccess file, but the odd thing that seems out of place in this issue is the bp_pc_redir_to parameter in your URL. A quick search yielded this topic about a similar issue where the parameter appeared and this page for the plugin BuddyPress Private Community. There appear to be a number of reports of this plugin not working with WP 3.3.1, so it could be this plugin that’s causing issues. I’d say try checking out the FAQ and your settings to see if something’s off.

I hope this helps!

Ok, thanks for the info. May need to give this a bit more testing, but making the following code change appears to resolve the issue:

In styles.css, in #access ul ul
Remove “top: 18px;” (line 427)
(Appears to work in Chrome latest, Firefox latest, and IE 7+)

It looks like having two lines of menu items with that particular theme is causing weird side effects by pushing the menus down further than where they should be. Getting rid of that line should resolve the issue by letting the browser’s default positioning take control of the menu’s placement.

Dunno what the effect of removing that CSS rule and scaling the menu back to one line would be. If doing both actions causes regression, adding the CSS line back in might fix the issue again.

I hope this helps!

I believe they’re using a slightly modified version of bbPress (https://bbpress.org/), a message board plugin for WordPress.

I hope this helps!

Welllll… Self-Hosted WordPress software is not exactly the same as Network-Hosted WordPress.com. They both use the same base software (WordPress), but other than that, they’re completely different.

So, with that said, your WordPress.com account credentials won’t work on your self-hosted version. Nor will any of your data carry over by default. The two are totally separate from one another.

Hopefully this FAQ on the topic will help clear things up a bit.

Now, if you do intend to migrate your site from a network-hosted site to a self-hosted site, thankfully this process is made a little simpler by the use of the Export and Import tool. This tool will create a data file that you can import into your new self-hosted site and will include your posts, categories, tags, and comments. Note however this tool won’t bring over your media files for you – the exported data will point to media files on the old site. You’ll need to manually go through and re-upload and re-link your media content to get this working. Learn more about importing here.

I hope this helps!

Hmm… appears to be working on my end. My guess is that there was some hiccup somewhere in your DNS cache, though it seems odd some pages would show correctly, then it would switch back to .com. That said, DNS caching can be fickle sometimes, so I wouldn’t rule it out entirely.

Was it a particular page that was causing issues? If so, maybe it’s an issue with that specific link pointing back to your old site.

I hope this helps!