Forum Replies Created
@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.
In a few weeks, we'll be launching a site for a client that will use some sophisticated search technology we've put together using faceting and Elastic Search. I think it will deliver great search results, but the package we've put together will only be available to clients that host with us. Elastic Search is a sophisticated search engine used by Foursquare and others for searching, so it's not a simple "upload and activate" WP plugin. I think Elastic Search-powered faceted search is the wave of the future for upper-end WP sites, and it will trickle down to the masses over time. Automattic already has it on their VIP service. Anything tied to the built-in WP search or that doesn't use a separate engine likely won't deliver great results.
If that's of interest, I'm happy to discuss it further.
1) Just about anything is widgetable. You would do that by taking the function the slider uses for output and turning it into a shortcode; you'd then enable shortcodes in widgets and put a shortcode in a text widget that would return (not echo) that output. It's some small amount of PHP, but technically possible.
2) We do managed WP hosting, and we have available other plugins that have similar features, with widgets or with functions that can be turned into shortcodes. If you're finding these types of questions unanswered, they are the kind of questions we routinely answer as support for our hosting customers. I'm offering that because of the apparent frustration in your question. If that might help, we can continue the dialogue off the forum.
@david Chu -
The other part of your question is complex.
Here's a simple solution to what might appear to be a complex problem:
Design your plugin so you add a function to the init action, as in:
add_action(' init' ,'my_custom_function');
That overcomes the loading order where plugins load after a theme's functions.php. There are other action hooks that come after functions.php is loaded. We have many custom plugins that use genesis functions, and all work fine. It's only a problem if you don't take WP core loading order into consideration.
@jhguynn - Glad it helped. With respect to Backup Buddy, a lot of folks swear the program works for them, and that's great. There are also a lot of affiliate links promoting the plugin. I'm not suggesting that anyone that uses an affiliate link and promotes the product does so with bad intent. Those that promote it and earn an affiliate commission from a web visitor following the affiliate link and buying the product might really believe it's the best backup solution. But I have worked with sites that bought the program, had about 2k posts/pages, and regularly failed to backup on shared hosts. Another feature that is heavily timing dependent is putting a backup file on a cloud service such as AWS, so I've seen situations where backups took place but never got placed onto the cloud service, so on server failure, the backup that never made it to a separate cloud service was lost.
With respect to Backup Buddy on Multisite, in the fall of 2011 they announced their multisite backup capability was in beta testing. See this wpcandy article from that time for confirmation.
In September of 2011 - 2 years ago, the company was promoting Backup Buddy's multisite capability, as this link from that period shows.
As of today, the latest Backup Buddy codex page on multisite says:
Again, BackupBuddy Multisite is an EXPERIMENTAL product. As such, we cannot support any issues encountered.
(their emphasis, not mine)
Promote. Take money. Cannot support. That's not a recipe I support or endorse.
BackupBuddy is rather awesome for most users and hosting
I couldn't disagree more strongly. I'd recommend pen and paper over BackupBuddy. BackupBuddy oversold its capabilities, encouraging people to buy before the program worked and hid behind the statement that it was beta software. Programs like BackupBuddy will inherently have problems on shared hosts because of scripts timing out. There are variations of settings and endless discussions of ways to circumvent the timeouts, but at the end of the day, these are problems inherent with any PHP-based approach to backing up a reasonable-sized database. IMO, most of those that love BackupBuddy either have small databases or have never used it to move a broad mix of sites.
@jessicakstudio - "Tools Export" will create an XML file which can be used by the corresponding Import function. For a small site, it works reasonably well, provided you keep in mind that it does not export data in tables outside of WP. For example, Gravity Forms puts its data in tables outside of the normal WP tables, so the export option won't help you there. The problems come on import, because many find that the Importer breaks. It's being re-written to fix some of the problems, and last I checked, the re-write was in beta but wasn't complete.
We do managed WP hosting, and I think the biggest thing we've learned over time is that any backup system is only as good as your ability to restore from it. Many of the PHP-based backup systems, including the WP Importer, fall apart when restoring or importing data, especially for even moderately sized sites.
If you're going to rely on any backup system, before developing strong convictions about your backup method, do a complete restore to see how well your system worked. I think many advocates of PHP-based systems will be disappointed in what they discover. If your host is not worrying about your backups (and many don't) and you don't want to change hosts, about the best method is to use phpMyAdmin to do a SQL dump and use a separate method to backup uploaded media.
If you want to push ahead on your own, you'd be well advised to either use Firebug with Firefox or Chrome inspector. There might be similar functionality for IE or Safari, but I don't use those browsers much.
With these tools, you can inspect which CSS is operating on which element. Doing that inspection should answer your questions.
In general, it's not as easy as removing the _1. First you're using ID's, not classes. You need to use classes to generalize the styling you are making across your site. Second, you always have to keep in mind that more specificity trumps less in determining which CSS applies. Sometimes, GF is very specific in their CSS, so to get your CSS to work, you have to find something that is more specific. Third, the GF CSS is specific to what you put on your forms, so you may think you've styles all your forms perfectly, and that might only remain true until you add a new field type to your form.
There is a big difference between styling form X to match a site compared to styling any form GF can create to match.
For your color line, see my comment regarding adding !important
Here, you have to do:
color: #fff !important;
Note that while these methods work, for others reading this they aren't necessarily what I would call the "best practices" method, because you are targeting a single form on your site. Since Gravity Forms users tend to use multiple forms on a site, you would be better off investing the time to apply site-wide styling to your forms that is consistent with the overall look of your site. That is, don't use form-specific ID's when targeting your CSS.
Hope that helps.
@mborger - First, some clarifications...
1) When you use ID targeting, as in #gform_wrapper_1, you are targeting a specific form (form ID 1), so you don't need to use !important. My previous comment was from a quick read of the issue. The downside to this targeting is that it only applies to this form.
2) In general, 90% of Gravity Forms styling issues can be solved by using !important when you are trying to style all the forms across a site the same way (which is what most people want). Thus, my suggestion for !important. To do this, you'd target classes rather than ID's.
3) I just took a look at your site and added a style declaration that used #gform_wrapper_1 to set a border, just as you did in your original post (with "body" removed, as suggested by @robin). It worked fine. I didn't see any of these changes in your stylesheet,, so the fact that you are not seeing suggests it is a caching issue. To debug something like this, you are better off turning off caching until you have the solution in hand.
@robin - That means his stylesheet is coming from a CNAME'd CDN, or content delivery network, due to his caching setup.