Forum Replies Created
August 13, 2014 at 3:22 pm in reply to: Developers: How do you handle dissatisfied clients? #118649
@Au Couer - I agree with most of what Lauren has already said. Here are some additional thoughts:
- if you don't respect your time, don't expect that your clients will respect it. If you do work and decide to discount it to $0, prepare an invoice showing the real value and the discount you applied. Be sure that invoice is read. Don't ever work for nothing.
- Some of the best decisions you'll ever make are deciding to break up with a client. Don't worry about pleasing every client. Worry about pleasing the clients who respect your work enough to pay for it.
- Some people want to complain about their problems. Others want to fix them. Stick to those clients who are prepared to keep their eyes on the fixing and avoid the complaining. Cheerfully point out to your client that there's obviously been a misunderstanding, mostly attributable to the personnel change on their end that had nothing to do with you. As a client, you want them to be happy, and the quickest way to get them happy is for them to itemize via email in as detailed a fashion as possible what's wrong, and what they would like you to do to fix it so that they're happy. Be upfront and explain that you'll review the list, but their including something on the list does not mean that you will do it for free or even for a fee. If you get an email with an itemized list, make a business decision about the cost of what they want and the discount if any you're prepared to give. If you decide to proceed, get payment on your normal terms, deliver what's on the list, and hopefully things improve. If you give a discount, put a deadline on it.
- If the client doesn't send an email after 30 days, re-initiate contact via email, saying that you haven't heard from them in 30 days, and that while you'd still love to make them happy, you respect their decision if they don't have the time to devote to the project or are pursuing it with another designer/developer.
- Confidently tell the client that you value them as a client and feel that you delivered great work that fully satisfied the original specifications, but if they'd like referrals to other developers/designers, you're happy to provide a few names of others who have the skills for the job. If they ask for such referrals, provide them and wish them well.
Hope that helps.
I don't have any experience with Updraft, so I can't comment on it specifically. Backup plugins can introduce security issues, but in that sense they're like other plugins. WP DB-Backup had a security issue a few years ago, but it was resolved by the plugin author very quickly. In and of themselves, backup plugins are no more of a security risk than other plugins, if you do reasonable due diligence on the plugin itself.
What prompted me to comment was your combination of updating plugins and security. Good security really starts with proper site configuration. (I've made a number of old posts on this topic that are probably findable via the search function.) In this regard, the vast majority of WP self-hosted sites are configured to compromise security to make plugin and WP updates easier. That's because to enable updating via the dashboard, the wp-content folder must be writable, but making the folder writable is the single biggest security vulnerability. You can't have easy updates and best security practices.
On your general security concern and keeping WP sites up to date and backed up, we do managed WP hosting, where we handle updates and backups. Our wp-content folder is not writable except through highly secure SSH, and that closes the door on a lot of potential attacks. If security is a big concern, you may want to consider hardening your site or having it hosted in a more secure environment. Otherwise, you're trading security for ease of use, which may not be a good trade over the long haul.
@jmrallen - We do performance oriented managed WP hosting and we'd love to welcome you as a customer if it's a good fit for you. Our plan that's most relevant is $20/mo, and in almost all cases, there wouldn't be any overage charges.
Your post focuses on unique visitor counts, and while that's a very important metric, it's not one we (and perhaps most hosts) care much about. We're focused on bandwidth. Thus, assuming your site is a typical website, my statement on no overages would apply. If 100k unique visitors were watching 2 hour HD feature films hosted from our servers (which would gobble up the bandwidth), we might have to have a friendly chat 🙂
You'd find that our performance and support are strong. My forum signature contains a link to our site, and if it looks like it's of interest, just reach out via our contact form and we'll answer any questions you have.
@Davinder - I agree with you that you can have too much of all the things you mentioned.
The challenge is that speeding up a very slow site often involves reducing a little bit everywhere, because most people are unwilling to accept very drastic cuts in 1 particular area. For this site's menu items, it has some menus that go to a 3rd level, and it has both primary and secondary nav menus. All of that takes time to generate.
Menus aren't likely the primary reason this user's site is slow, but if one doesn't prune the menus, one has to take more from the other things you mentioned (images, scripts). Big menus like this also present big challenges on mobile responsive design, which this site isn't using. Personally, I also think the menus are a dizzying array of too many choices, and fewer choices would help guide visitors better. For all of those reasons, I think the existing number of menu items is too many.
If you're running a Genesis theme, here are a few places where the script might come from:
* a plugin or some settings for an activated plugin (only activated plugins count)
* your child theme's functions.php file or any files included automatically in that file
* the file that loads your theme's home page, sometimes home.php or front-page.php (or another template file used to load the page where you see the script)
* the Header and Footer Scripts metabox of your Genesis settings
* Genesis Simple Hooks (if you are using that plugin)
* the Scripts metabox of the single post/page editor
If you see the Aweber script on every page, then the last choice is less likely unless you are using a static home page on your site and only checked the home page for speed. Also, when you locate how the script is loaded, you'll want to make sure the script is enqueued. You'll probably be able to tell that based on how the script is added. While it is possible to simply echo the script in a location, if it is enqueued, it can be easily dequeued via a plugin (that acts like an on/off switch) in a situation where it's not responding.
@CruiseDirections - I'm going to respectfully disagree with some of what @Davinder said. While I agree that there is no actual limit on menu entries, the more menu entries you have, the longer it takes for your site to load. The incremental time for each menu entry is very small, but if you have a lot, it adds up. Your site is fairly slow, with page load times over 5 seconds. Since speed is factor in ranking on a SERP, to the extent that you get business from organic search traffic, that slowless is costing you money.
If your site otherwise loaded in 1 second and you had the number of menu items you do, I would agree with @Davinder that your menus aren't a problem. But since your site is slow, one of the solutions to get a much faster load time is probably going to include reducing the number of menu items you have.
Your performance has nothing directly to do with your theme in this case. Your slow performance is due to loading awt_analytics.js, apparently an Aweber script. If there is a difference in one theme to the next, it's likely caused by how you load it. If you load it the same way, difference in timing could be due to the response of their servers, not yours.
In 1 quick test, your site took over 27 seconds to load and the Aweber script represented about 22 seconds of that, so you have other factors making your site slow, but it is has absolutely nothing to do with the Sixteen Nine theme itself.
The simple answer is yes. You can read how Genesis assigns images to content in our article here, http://wpperform.com/genesis-framework-archive-images/.
The important takeaway from that is that it's possible to specify a "fallback" image when you haven't specified one of the other types of images, and it would be best to do that via a custom plugin. You just have to take care to actually specify a unique image where you want one and to make sure your starting fallback image is sized generously enough, so that if you change themes and regenerate image sizes, everything still looks good.
iPage is unreasonably cheap, and while we're lot more in percentage terms, the absolute dollar difference wouldn't buy a nice meal. I think if you have 1 question in a year's timeframe, it justifies that difference. We don't like to let money stand in the way of good relationships, so if you think we're a good fit, get in touch.
On "nothing anyone would try to steal", don't be naive. Bad actors aren't after your content. They are after a range of things, but a few bear mention: your traffic and your domain/reputation. A bad actor can leverage your traffic in a variety of ways and redirect it to their typically criminal schemes. A bad actor can take over your domain and then blackmail you to try to get it back. Most people on shared hosts don't review their server logs and would be shocked if they did. The volume of attack traffic goes up and down, but just about any WP site is being attacked many times every day, and that likely includes yours. I don't say that to scare you, because the vast majority of the "attacks" are scans for vulnerabilities that the attacker can exploit. But if your vigilance drops for an extended period, the odds of your site being compromised go up a lot. It's not that you aren't being attacked now, because in all likelihood you are. You're just unaware of those attacks because you're surviving them.
I'll try to save you some time on #2 and #3 - don't bother. You can read more on how we cover security here http://wpperform.com/wordpress-security/.
For #2, the login URL is hard-coded in WP in many places, so it would take modifications to WP core to achieve this, which would not be recommended.
For #3, it falls into the category of fixing 1 problem creates a bigger problem. Attempts to limit logins (or to run security-related code in WP) necessarily runs through PHP. Running that code slows down your site for all visitors.
If you attempt to limit logins via PHP, attackers can can inadvertently create a DoS (denial of service) attack on your site by repeatedly triggering your code to keep them out. Our article discusses why you can never have great WP security on a shared server, but if you are on a shared server and don't want to/can't switch, your best approach is to use secure, complex passwords and to use 2 factor authentication - and that's it. If you try to do too much security in the wrong hosting environment, you can very easily create situations where you're site isn't available. Attacks are real and frequent, but stopping brute force attacks are just 1 of many challenges you have running a WP site.
Even though you are using Genesis, you aren't limited to Genesis hooks. WP has hooks too.
Try init, as in:
add_action( 'init', 'somefunction' );
This will give you a sense of the core loading order in WP, which will point you in the right direction.
@William - We do managed hosting, and I think you'd be pleasantly surprised about our pricing. If you're interested to discuss further, just drop us a note using the email link in my signature.
Here's a site we built for a client, http://www.mostresource.org. It's running about 30 plugins (including some hefty ones, like NGG). Cached pages ought to be served up in about 600 ms (6/10 of a second) or less; uncached pages in slightly more, but well under 2 seconds. I think it would be very, very difficult, if not impossible, to serve a complex site like this on a single VPS as quickly as we serve it, especially with high traffic loads.
Nginx is the way you want to go if you opt to become your own server admin. The challenge is that being a server admin leaves all of those unglamorous tasks (optimizing the server, backups, security) to you, which is time away from content creation. If you have the interest to tinker, it's fun to learn. However, at the end of the day, you have 1 VPS talking to 1 DB server, whereas those doing managed WP hosting like us have multiple web servers talking to multiple DB servers, and that redundancy provides a level of protection that you don't get with 1 VPS, even if you manage to tweak the performance to try to come close to the performance of managed WP hosting.
October 4, 2013 at 1:51 pm in reply to: Can I Keep HTML Pages So I Don't Have To Redirect? #65388
@Tom - You're right about the permalink change to which I linked not working with pages, but that is easily fixed with a small plugin. Generally speaking, I don't disagree with what you said about whether doing what the OP originally asked makes sense. I was only pointing out that it's possible. What's possible is not always what's wise.
@DonnaE - If you have less than 50 pages and you've moved a site to WP, you're better off redirecting the .html links to their new locations on your WP site. Links do suffer some very small hit from an SEO perspective if they are 301 redirects, but in the overall scheme of things, it's inconsequential. The structure of your permalink (including whether the category is preserved in category archives) is controllable.
If you're comfortable doing .htaccess redirects, they're faster than redirects via a plugin and as Tom pointed out, it's one less plugin that you have to master.
October 4, 2013 at 7:49 am in reply to: Can I Keep HTML Pages So I Don't Have To Redirect? #65345
@Tom - That's not accurate. WP's permalink settings allow for great flexibility.
Here's a simple way to do this. I recall from years ago that there used to be an issue with page permalinks (not posts), but this may have been fixed in later WP updates. Be sure to test permalinks of all content types.
@Mary OBrien - Here are some suggestions/comments:
1) You do have issues with mobile responsive design, but not quite what you're described. Mobile responsive design is tied to screen width, not the device's OS, so that's why something can work on an iPad but appear broken on an iPhone using the same OS or browser version. Those devices have different screen widths.
2) Your site doesn't appear to be running HTML5.
3) Don't worry about iOS versions or devices just yet. Simply drag your browser to a set width for basic testing. If you drag your browser to a narrow width, you will see that your header is too wide for an iPhone. Other elements look good.
4) Once you have your basic responsive design working, then you can begin looking at the site on different devices.
For #3, there are different ways to simulate the specific width of a device, depending on your browser. In Google Chrome, you can hit F12 to bring up developer tools. In the lower right, you'll see a gear icon for settings. Click it. Click the Overrides menu selection, and choose your device or browser overrides. Be sure to enable them so that they show up. This allows you to navigate your site using Google chrome and appearing to be a device (or another browser). You'd explore your site using this tool and adjust your mobile responsive CSS as necessary to fix the problems you discover. There are other tools for other browsers.
How to fix everything that you don't like is a separate discussion, but that should point you in the right direction to identifying where the problems are.
Hope that helps.
@Burtieboy - We do managed WP hosting, and most small modifications would be included free of charge as part of our ticket-based email support. Bigger customizations all the way up to custom theme development outside the scope of free support are also available.
If that's of interest, just drop us an email through the link in my signature.