Forum Replies Created
-
AuthorPosts
-
Bill MurrayMember
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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMember1) 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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMember@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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMember@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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMemberBackupBuddy 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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMemberIf 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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMemberFor 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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMember@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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMemberYou need to add !important on all of those declarations, as in:
border: 1px solid #000 !important;
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMemberIt works perfectly for me in a number of tests. What exactly do you mean by "tried everything"?
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
August 29, 2013 at 7:47 am in reply to: Minimum Pro – How can I control the background image re-sizing #59516Bill MurrayMember@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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMemberYour 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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMember"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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
August 27, 2013 at 3:06 pm in reply to: Education Theme no longer lands mobile viewers on the home page #59113Bill MurrayMemberIt'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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMemberSteve - 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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMemberMy 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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMember@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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMember@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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMemberThe solution is simple: make sure the files exist and are readable by a public visitor in the location specified.
For example, this file:
http://tenocation.com/wp-content/themes/wps/images/icon-tag.png
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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
Bill MurrayMemberAs 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.
Web: https://wpperform.com or Twitter: @wpperform
We do managed WordPress hosting.
-
AuthorPosts