Morten Rand-Hendriksen

This is easy to fix: Just reinstall WordPress locally by following the install procedure. Then you can use WP Migrate DB to find the correct file location.

If after a migration you land on the WordPress installer page, it almost always means the database prefix in your migrated database does not match the table_prefix value in wp-config.php. Without matching tables, WordPress asks for new ones to be created through the install process.

From what I can tell, DesktopServer uses the standard table prefix “wp_”, so my guess is the site you are exporting from has a different prefix. It is also possible the prefix in your particular DesktopServer site has a different prefix.

To find out, open wp-config.php in your DesktopServer install and look for table_prefix. Make sure the prefix defined there matches the prefixes in the database tables of your exported site (you see them in phpMyAdmin at the beginning of each table name.) If the prefixes do not match, you know what the problem is. To solve this, you can either try to change the table_prefix setting in DesktopServer (just remember what the original setting was in case you want to switch back), or you can use the automatic Pull feature in WP Migrate DB Pro to handle the transfer seamlessly.

For reference, this particular issue is addressed in the course in the movie called “The importance of matching table prefixes”: https://www.lynda.com/WP-Migrate-DB-Pro-tutorials/importance-matching-table-prefixes/472837/476570-4.html

This would be classified as unexpected behavior and is not something I would recommend doing. If you want images to link to attachment pages, they should be in post content.

For clarity, the original simone_the_responsive_thumbnail() function was added before WordPress had RICG Responsive Images in core. When that was shipped, the function was removed to prevent a doubling up of functionality.

The solution suggested here is sound. If someone submits a pull request to the repo, I’ll add it in so you get credit. https://github.com/mor10/simone

This means the theme “HERWEBSITE” is a child theme based on dkret3, which is not installed. It has nothing to do with Simone or any of the other themes.

“The header features an optional social media menu which is displayed on the far right of the menu area. Social media icons from Font Awesome are automatically generated based on the URLs of different social media services so a link menu item with a Twitter URL will automatically show the Twitter icon etc. To activate the menu simply create a new menu and assign it to the Social Menu template location.”

https://mor10.com/simone-wordpress-theme/

IE8 should be fine. IE7 will degrade gracefully.

The sidebar only appears on quite wide screens.

It can, but was not part of the original UX design. You can lift some code from Twenty Sixteen to make it automatic.

This is intended behavior. To change it you have to change how the header is displayed in header.php through a child theme. The code you need to change is on line 53:

https://github.com/mor10/popper/blob/master/header.php#L53

Simply removing the code inside the PHP delimiters will trigger the full header to display on all posts, pages, and elsewhere.

If you want to add a feature to the theme to make this an option, add an issue in the Github repo linked above and I’ll consider it for a future version.

The header, as you describe it, is not broken. This theme is designed to put the content in focus. The full header only appears at the top of the front page and first-page index pages. For the rest of the site, on wide displays the header displays as a narrow band across the top of the layout which serves as a background for the menu. On narrow screens, the header disappears entirely.

The theme is not built with WooCommerce support in mind, but it should work. As far as I remember, WooCommerce will generate the necessary pages automatically and you can add in the loops using shortcodes.

This question falls outside of regular theme support since it’s really about WooCommerce so I’m marking it as “Resolved”. Feel free to continue discussing though.

That’s weird. I have to test to see if I can reproduce.

This is actually an issue of proper content clipping. It’s been resolved on other content but I must have missed it on the header. I’ll update it in a future version. Meanwhile the correct solution to the problem is to change the CSS to the following:

.site-branding {
  position: absolute;
  clip: rect(1px, 1px, 1px, 1px);
  height: 1px; width: 1px;
  overflow: hidden;
}

The overflow: hidden; part will prevent the scrolling without removing the content entirely from the DOM.

Glad to see this resolved. I’m closing the ticket. Let me know if you need it reopened.