Welcome to the forum:
Welcome to the iThemes, PluginBuddy and WebDesign.com forum. We've created several tutorial video's to help you get you started with using the forum, please check them out!
Also take note of the forum guidelines.
Our moderators actively respond to forum support requests during normal business hours which are Monday-Friday, 8am - 5pm Central Standard Time, typically within one business day. Although some moderators choose to work during the weekends, we can not guarantee immediate attention to your requests. Thanks for understanding.
What is included with support:
Premium support includes theme/plugin issues such as: bugs encountered under normal operation, how to use basic features, basic WordPress help, and basic help with customization (meaning we point you to resources and will help in more depth as time allows). More information.
Enable Http Loopback Connections?backup_buddy
Posted 26 September 2012 - 12:29 PM
Posted 26 September 2012 - 01:53 PM
In order to have access to the appropriate support forum, you'd need to be able to login using your username and password. If your client is able to login, they can go to the BackupBuddy forum and ask there.
I will tell you, however, the best way to find out how to make that change is to talk directly to the host. They can typically make the changes you need for you, but should be able to at least walk you through it.
Posted 26 September 2012 - 05:31 PM
Posted 02 October 2012 - 06:21 AM
It's not something we can advise on because it is wholly dependent on the server environment and how that is set up by the host. It is, however, required for proper execution of WordPress task scheduling so if the mechanism is not working in your server environment then that aspect of WordPress (which is used by WordPress core and various plugins of which BackupBuddy is just one such) will not function and certain capabilities will not be available to hosted WordPress sites. BackupBuddy does provide some capability to provide backups in the case of a server with such limitations but I cannot speak for other plugins or WordPress itself as to how they may cope with the limitation.
I can tell you that using the loopback network as you have indicated you have tried is one such approach to mimicking an http loopback capability and is most often used on private development "servers" (such as desktop machines) and certainly is a functional alternative in such cases (where private urls are almost certainly is use) although we don't particularly recommend it as a solution for live server environments as it is not a specific http loopback capability but a more generic loopback device.
WordPress does provide a workaround (known as the alternate cron) which can be enabled in the wp-config.php file but this can have side-effects that site owners may consider unacceptable and so isn't particularly recommended.
I would suggest contacting the support for your particular server and/or server environment to see if they can advise on the specific configuration required for your server environment to enable http loopbacks so that WordPress can function correctly for your clients, thanks.
"Everything will be all right in the end. If it isn't all right yet then it isn't the end."
Posted 05 October 2012 - 11:20 AM
It's strange, we have about 20 wordpress installs on this server and they are all functioning as they should...
I'm using a vanilla LAMP stack built on CentOS 6.3. I've been googling around, but I can't find any mention of configuring HTTP Loopback. You say using the loopback interface 127.0.0.1 is only mimicking this capability, but this is the only type of loopback I know of.
When googling "HTTP Loopback Connection" most of results seem to pertain directly to BackupBuddy -- do you know if there's another term that Linux or Apache uses for this function?
Posted 10 October 2012 - 01:21 PM
If your sites are functioning as they should then you imply that you are having no problems with http loopback connections so if you have any particular instances where there are problems then you need to look for other causes.
Just by way of information (for anyone else who might read this topic) a standard test to see if WordPress task scheduling is working or not is whether you can make _scheduled_ posts, i.e., write a post and schedule it to be published some time in the future - if this works then http loopbacks are working ok, if it doesn't then you have _some_ sort of a problem which may be the hosting loopback functionality or something related to the site itself (many people get caught out because they may have a maintenance mode type plugin enabled (or a theme with similar capability enabled) as usually these block the access required for the WordPress task scheduling to work.
Problems with task scheduling are not uncommon and can relate to having too many overdue tasks ready to run - WP has built-in throttling so that if there are a bunch of overdue tasks that would be run it may be that only some of them are run and there is a delay before the next "batch" are allowed to run. If the site is generating a lot of scheduled tasks (either through WP core activity or plugin/theme activity) then things can get stuck.
We use the term "http loopback" as a convenient shorthand phrase in place of things like "the site being able to establish a connection back to itself" which is pretty cumbersome ;-) It merely means that specifically for http protocol the site is able to send a request to itself (using its actual url) and that request will end up being processed by the site as would any other request to that url. So this doesn't imply it is a general "lloopback" capability which might work for any protocol. Of course this also implies that data connections can also be made in the same manner.
This is not a specific term related to any operating system or server and the capability is not specific to any operating system or server. It really relates to a hosting "environment" in which, within the hosting environment, a site on a server is able to send an http request out to its own url and the hosting environment, one way or another, allows that request to end up back on the server being directed to that site - simple as that.
When talking about IP address 127.0.0.1 this is related to the common loopback network/interface/device which is a virtual network interface in which any traffic sent is handled purely internally to the computer, it never leaves the machine on which it originates. Making use of this is certainly _one_ way to provide a loopback that should support http connections and as mentioned previously is very commonly used on development systems, but of course has many uses beyond this. AFAIK though this is _not_ how http loopbacks are supported in shared server environments because it usually depends on making updates to a /etc/hosts or similar file and I don't believe that is something that hosts do on shared servers. However, in shared server cases where http loopbacks are not supported it often seems to be the case that a host may try and upsell a Customer to a VPS by telling them that http loopbacks are supported on VPS - in fact what they really mean is that you can edit your /etc/hosts file to use the "loopback network" as above.
In the general case when a site issues a http request to its own url the traffic will leave the server (as it would with any other request) and go into the hosts network infrastructure and be subject to various routing and other operations and would eventually end up back on the server directed to the site. This mechanism allows for processing of packets for whatever reasons are required, perhaps to stop infinite loops or similar.
So, if you are running a VPS and "hosting" client sites in a sense you are not the real host but more o a "virtual" host as your VPS is still a component within the overall hosting infrastructure of the host who actually owns the VPS. So whether http loopbacks are supported depends on that host and not specifically on you although you can choose to provide _a_ loopback capability through the loopback interface.
That's pretty much it really according to my general understanding. But I wouldn't claim to be an expert in "hosting" as I don't run a hosting company or environment so you may have additional information or insight that can clarify or further inform certain aspect of this.
However, whether or not there are any specific inaccuracies in the above or any missing information is largely immaterial as the bottom line is that for a host/server to fully support WordPress it must support the ability of the site to send an http request to its own url and for that request to be delivered to the site for processing. If the hosting environment isn't supporting that then it simply isn't fully supporting WordPress.
"Everything will be all right in the end. If it isn't all right yet then it isn't the end."
Posted 19 October 2012 - 01:15 PM
"the site being able to establish a connection back to itself" is very clear and in this case there is no problem. When I log into a shell, I'm able to use CURL and WGET with the site's hostname and it connects fine. This is enough evidence for me to tell the hosting client that the issue does not reside on the server.