Forum Replies Created
August 29, 2013 at 7:47 am in reply to: Minimum Pro – How can I control the background image re-sizing #59516
@coralseait - What you're seeing on screen widths less than 1024px is the actual impact of the theme's CSS. See lines 1673-1675 of the child theme's stylesheet.
At screen widths of 600px or less, a mobile menu kicks in, which changes the header again. Thus, there is this spot of screen widths between 1023px and 601px where the menu is not fixed but also not the mobile version.
Whether that's by design or not, I can't say.
You might want to raise this in a support ticket to see if that's the intended behavior and post back with what you learn. It's easy enough to change in CSS either way.
Your current image (with the "river tour" boat) looks pretty, but the image is WAY too big. The image dimensions are 4134 x 1656 px. Do you regularly bump into visitors who have displays that are 4134 px wide? It's over 2 Mb in size. It causes your site to take forever to load and will be a real traffic-stopper. In addition to finding a pretty image, you need to pay attention to those details.
"Disaster" is a bit harsh.
What's wrong with your image? It looks to me like you've got a really vivid image and it looks sharp. What do you think is wrong or what do you want to change?
It's fairly straightforward to get an image to look good in the space. For one, start with an image that is 1600 px wide X 1050 px high.
August 27, 2013 at 3:06 pm in reply to: Education Theme no longer lands mobile viewers on the home page #59113
It's not likely that the Genesis upgrade caused it. I can confirm the issue you're seeing.
I see you're running Jetpack. Check that the appropriate modules are activated. Your site is mobile responsive. You can test that yourself by changing the width of your browser. However, something is bypassing that, and Jetpack is one option.
This suggests a plugin issue, so if it is not Jetpack, you might have to go the standard debugging route of deactivating all plugins, testing on a mobile device, and reactivate 1 x 1 until you see the problem start again. That's when you've identified the culprit.
Steve - Since we're communicating offline, I may have mentioned this in emails we've exchanged, but for the benefit of others - we have that info for every theme we offer. It should make it easy for you to narrow down the list of available themes to arrive at those that are suitable to your needs.
@angela - Thomas Griffin from Soliloquy might hate me for saying this, but I read more and more about how sliders are dying. Most sliders auto-advance faster than people can absorb relevant info, and studies suggest that sliders negatively impact conversions. They are pretty, though.
My opinion is that you should switch to HTML5, but the way we do it makes that very easy. We do managed WP hosting, so the ease comes from how we've set this up, and that influences my answer to whether you should switch.
First, if you were a client of ours, you would not be changing the Metro stylesheet directly. You'd be applying your changes to it via a separately maintained stylesheet, with tracked revisions. The benefit of that is that your revisions are separate from the "base" design. That makes it easy to switch from one theme to another.
Second, when Metro w/HTML5 support is released, we will include both themes, the XHTML version and the HTML5 version. If you wanted to switch the minute the HTML5 version is released, you'd simply activate that new theme and adjust only your revised CSS, which might require no revision at all. Your site display might break for as long as it took for you to make those revisions.
If you didn't want to break your site for an instant, we'd set up a copy of your site on which you'd activate the new HTML5 version of Metro. You'd make your changes as your time permitted. When you were ready, when change a pointer that would point your site to the new HTML5 version instead of the XHTML version.
That process makes it easy to switch themes as they are updated, which is one of the features of our managed hosting. The process can be easy, but you'll have to measure how hard it would be for you to make the change in your current setup against the benefits of having HTML5, which will grow over time. At some point you'll want to use HTML5, so it's a matter of when you get on that bandwagon, not if. It's easier to do something like this pre-launch than post-launch.
Hope that helps.
@sundance - To clarify: on your server, you would have at least 2 users: 1 would represent the public web visitor and the other would be a user that is less powerful than your server root user, but who has write permissions to the WP folders. If you have a functioning site, you already have a user that represents your public web visitor. You might have to reduce the powers you've given that user.
For your entire WP folder structure except for your uploads directory, you set it so your public web visitor only has read permissions, but the more powerful non-public visitor has write permissions. Of course, once you do this, don't expect to be able to do dashboard updates to anything again. Instead, you'd use something like wget to retrieve a zip of whatever you want to upgrade directly to your server. You can retrieve WP core updates and plugins in the WP repo this way. I asked many months ago if SP supported this method, and I recall either Brian or Nick said no, so for Genesis updates, you'd have to go a different route. Obviously, these methods require that you be in control of your own server and not on a shared hosting plan.
Your uploads directory must be writable by the public web visitor so you can upload media. If you use any other plugin that uses something similar to uploads or caching (such as W3TC), the folders those plugins use must also be writable by the public web user. If those plugins can be set to store their data under /uploads (which is writable), you should be all set.
Then, you'd SSH to your server with the other, more powerful user and manage your WP installation.
This is more work, but it provides a lot more security. It will seem that is hard to give up dashboard updates at first, but once you get the hang of this method, you'll be comfortable and productive.
@odg - #4 is not specifically tied to an injection attack; #1 is.
Let me explain. In order for a web visitor to be able to view your site, the visitor needs to be able to read the files. When you use a browser to access your dashboard, you are a web visitor. On your WP install, a web visitor can write to files in your WP folder - that's how YOU can do upgrades via your dashboard. When I refer to read and write permissions, I am referring to permissions set at the server level. Just like you use a user account to log into your PC, servers make use of user accounts, among other things, for security. On your server setup, the server user accessing your WP files has both read and write permissions. That's not all an attacker needs, but you've already given away a lot. It's as if you left the front door to your home unlocked. What happens next is not up to you, it's up to the attacker. This setup is required to let you do upgrades through your WP dashboard because WP needs write capability to update itself. The same applies to themes and plugins. In effect, you've traded a lot of security to get some convenience.
In contrast, on my server, the server user accessing those files can only read them - not write to them or search the folders. I could give you my WP login credentials, and they wouldn't do you much good if your goal were to launch an injection attack, because you can't modify the code in my WP install. This is the vulnerability you open when you allow for in-dashboard upgrades. Nearly all serious WP professionals are accessing their sites through SSH terminal and they are doing upgrades not through the dashboard but through other tools, because this closes this vulnerability.
#4 is related to a different issue. If you show author archives on your site, by default, the archive link is a link to your actual username - no matter what you choose to display. Try it and see. Therefore, if I visit your site and you show an author archive, you've already given me your username, which is 1/2 of the info needed to break into your site. With that information, I can run something called a dictionary attack on your account (which is most likely an admin account). A dictionary attack with even a modestly large # of infected PC's acting together could break into 95%+ of installs in a very short time. If you monitor your network traffic, and your site has been out there for even a short period of time (say > 30 days), you will find that your site has been attacked by a brute force attack. You could have been the victim of an injection attack through this method IF you allow a web visitor to edit code (because that visitor, once having succeeded in the brute force attack, could use dashboard tools to edit your PHP files). Most WP sites are the targets of brute force attacks, and tools like Wordfence can reduce them. My point in the original post is that if you are serious about security, it is far better to lock the front door and take away write permissions from your WP folder. (Note - you do need write permissions for the /uploads folder; otherwise, you couldn't upload media. Therefore, you set different permissions for just this folder but supplement this with a restriction on what can be uploaded to this folder and what it can be used to do.)
If you had implemented the 6 steps I recommended, in all likelihood your site never would have been hacked. We do managed WP hosting and have had days where network wide we have seen 30,000 attacks. We implement all of those steps (plus a few more), and I haven't seen an attack succeed. No one can promise a future-proof security solution, but those steps are very hard to defeat.
Hope that helps.
The solution is simple: make sure the files exist and are readable by a public visitor in the location specified.
For example, this file:
generates a 404.
That means it either isn't in that location (and remember - web URL's are case sensitive) or it is there but a public visitor does not have permission to read it.
You'll need to access your server and examine the files and folder structure to track this down. You can simply try to open one of the 404 errors reported by Redirection in your browser to see if you've fixed the problem. When the image opens fine, the 404 will go away.
As someone who deals with this regularly, I'll take a different approach: the best WP security plugin is none at all.
First, on some of those mentioned. Mark @ Wordfence is great, and I've offered Mark suggestions on ways to make his plugin better. A while ago, he implemented one of my suggestions on ways to make IP spoofing harder (which used to be much easier using Wordfence). However, for much of what Wordfence does, there are better ways to do it - provided you are willing to get serious about security. On Jeff Starr's BBQ: great in concept, and Jeff contributes a lot of great WP info. However, on BBQ (which are based on URL length), you'll quickly find that a mix of plugins on a WP site can very easily result in long URLs, and if you block them, your site will break. Many long URL's are malicious, but not all of them are, and it's difficult to tell using an automated tool. Jesse's Stealth Login plugin also has a lot of potential, but it really is just an attempt to move the login URL to make your site less susceptible to brute force attacks. If you get serious about security, brute force attacks are very difficult to pull off.
Getting serious about security means ...
1) Giving up updating from within the WP dashboard (core WP, themes, and plugins) - this is something most refuse to do
2) Never accessing your site with FTP; use SFTP at a minimum and preferably SSH
3) Using security that gives users the lowest role they need to complete their task - don't make everyone an admin
4) Not using common usernames (eg, admin) and changing your user archive URLs to something other than the username - that removes 1/2 of the information needed in a brute force attack
5) Using complex passwords that vary from site to site among the sites you visit
6) Keeping the PC's from which you access your site free of viruses and malware (the common source of compromised sites)
If you follow those 6 steps, you can skip running any WP security plugin. Your site will be faster but no less secure.
August 23, 2013 at 9:25 pm in reply to: Core wordpress files/child theme alteration questions #58565
1) On your "3 comment" requirement, the right way to go about this would be to use some hook to modify core WP behavior, implemented as part of a custom plugin. There are a number of filters that can probably do this, but they'd require writing a custom function to connect to the WP comment system. My quick comment is that this is an intermediate-level project, and if you're not comfortable with PHP code, be prepared to spend a bit of time on it. This filter might get you headed in the right direction. It's also possible there is an existing plugin for this, but none comes to mind.
2) Your best for your welcome box is to add a widget area if your theme does not already have one, and then put a text widget there with your markup and content. You'd need to a) create the widget area, b) put it in your home page template, and c) update the CSS (including the responsive CSS) for it. The specifics will depend on your theme.
Hope that helps.
August 23, 2013 at 9:10 pm in reply to: How To Upgrade AgentPress 1 to version 2 Existing Site #58564
The best way to do this depends on your setup.
For minimal disruption to a live site, you need the ability to keep the existing site with AgentPress 1.0 and create a new development site with AgentPress 2.0. You'd suspend new content creation on the original site, block search engines (and possibly others) from the development site (if it's not local), and duplicate the content there. Then, you'd adjust the development site to look the way you want it. It wouldn't look exactly the same as the old site, otherwise it wouldn't be new and take advantage of new features. That approach allows you to give the transfer process sufficient time to do it right, because the live site is still up and running.
If you don't have a development site and try to do this on a live site (which is not ideal), the best advice is to work quickly
There's no way to ensure "minimal rework" unless you've already created the current site in accordance with some best practices, such as...
1) put custom code in plugins rather than modifying functions.php
2) separate custom CSS from the theme's CSS
Those 2 steps make it much easier to switch from 1 theme to the next, or to upgrade from 1 child theme version to the next. If you haven't done that already, all you can work toward is implementing those steps in the current update. That will make future changes easier, but it might actually make this one harder, because you're building for the future.
Steve - As I said in my original post, I'm happy to discuss the details via email. This forum isn't the best place for this type of back and forth. If you'd like, just send me a tweet and I'll reply. I'm just 1 of many here out in the WP world not affiliated with StudioPress who can assist you. I'm sure others will reply with different approaches/answers, of which there are many reasonable ones.
Good luck getting things sorted out.
@stevee00 - You might be a good candidate for our managed WP hosting.
1) You can try any theme we offer and switch between them as often as you like.
2) You can customize anything you want and we'll help you do it. That applies to colors, logos, fonts, sliders, etc.
3) WooCommerce is not a problem on our network.
4) HTML5: We have about 7 or 8 Genesis HTML5 themes (SP has 4, if you count the sample theme). Eleven40 Pro and Sixteen Nine and Going Green Pro are HTML5. The others you mentioned are not, but might be in the future. One HTML5 theme we have is tailored for ecommerce.
We handle all WP and plugin updates, security, backups, provide ticket-based email support. That leaves you free to focus on creating content. Rates are in the $10-$20/month area (varies by features, but what you listed is $10/month). If you prepay your 1st year, we'll move your existing site contents for free. If you're interested, we can discuss further via email.
Hope that helps.
@p1smh - The child themes DO put a class of site-header on the header div under HTML5.
Assuming you are using Genesis 2.0 and assuming your child theme has the line that @markelch correctly quoted, your child theme should include that markup. If it's not doing that, first check how you enabled HTML5 support in your child theme. If it's not as markmelch quoted, it's wrong. You'll also want to make sure your sample child theme is current as of release, since there were some changes made just prior to release that would impact this.