We are very aware of these issues and looking at possible solutions.
Answers. 1. I am using 3.5.3 on one of my sites with not problems. 2. The best answer I can give is "probably" as we would not be required to code in particular ways. |
I had the blank page problem after upgrading to WP 3.1 with 3.5.3. I then upgraded Atahualpa to 3.6.4 which didn't fix the problem. I tried all the suggestions in this thread and none of them fixed my problem.
I disabled all my plugins and it started working again. Unfortunately I couldn't find the exact plugin conflict. WPTouch and ShareThis seem to be involved with an incompatibility with some of the other plugins I run. It also appears that depending on the order they are activated effects the behavior as well. Marke markeclinger.com |
I just wanted to report that I am having the same issue (blank page) with Media Temple. I am getting the
ALERT - Include filename ('bfa://logoarea_style') is an URL that is not allowed error. I am trying to work with them to resolve this, but their support is very slow. Everything works fine with my other web hosts. Anyone use Media Temple and was able to resolve this? |
Hello from Russia.
Many thanks to the author of this theme. I have written the message to technical support of the a hosting of the provider. They have answered that at them is established on all servers suhosin-patch and it can't be cleaned. This patch of safety will stand now at all a hosting of providers. You need to correct your code that the template worked correctly, differently in any way. I very much like this template. In it it is easy to change options and to do style such what is necessary to me. Make please corrections in a code. All Russia will be grateful to you. |
Until a fix is found you could use Atahualpa 3.5.3 That is what I did with one of my sites.
Here is Google translate version of the above. I would be interested to know how accurate it is. До исправить найден, Вы можете использовать Атауальпа 3.5.3 Вот что я сделал с одним из моих сайтов. |
I have WP 3.1.1 installed with Ata 3.6.4, and I'm getting the dread blank page, although the site displays fine with the Twenty Ten theme.
I tried the above .htaccess lines, but they just produced a 500 error. This is what I have in the php.ini, but I still get the blank page: suhosin.executor.include.whitelist = bfa:// suPHP_ConfigPath /home/theapolo/ I really want to use this theme! Lane |
Did you also try the alternative syntax as show on post #1? Have you contacted your host to see if they can whitelist bfa://?
|
Larry,
When you say that you're still using 3.5.3, is that with 3.1.1wp? I can't afford any down time so I don't even want to mess with an upgrade that is so unstable & buggy. I'm shocked there isn't a fix yet. Jason |
I have one site with WP 3.1.1 that I am using Atahualpa 3.5.3 on.
|
GuruJ - it's not an Atahualpa bug, it is a host server security restriction and because every server seems to be configured differently, different solutions work different places.
At my host, my site never hit the problem. I installed it for one of my local customers and they hit it. Same host, two different servers configured different. |
Same with me, Juggledad. On my own server account, I never saw this. It appeared when I installed on a client's account with a different hosting company.
Trying the suggestions in this thread, this is what worked for me: Added to .htaccess in public_html suPHP_ConfigPath /home2/theapolo/ (I accidentally discovered that it should be home2 and not home) php.ini placed in / (one directory up from public_html): suhosin.executor.include.whitelist = bfa:// Lane |
My host just switched from Apache to Litespeed server. The /path/to/wwwroot/.htaccess and /root/php.ini fix to set suhosin.executor.include.whitelist doesn't work with this server.
I removed su_PHP_ConfigPath from .htaccess, and suhosin.executor.include.whitelist = bfa:// from php.ini. I instead added this to /path/to/wwwroot/.htaccess: Code:
php_value suhosin.executor.include.whitelist bfa:// |
The server where I had this problem and fixed it as noted above is running Apache version 2.2.17.
The server where I've never had this problem runs Apache version 2.2.15. I suspect this means there is some other reason for the difference than the server software and version. I will make a note of my solution and the Litespeed solution above, in case I run into this again. Lane |
We have just started a new project with Atahlaupa 3.6.4 on WordPress 3.0.5, no plugins so far, PHP Version 5.2.16-0+tld0, suhosin.log.phpscript.is_safe Off, off, suhosin config bellow:
This server is protected with the Suhosin Extension 0.9.32.1 Directive Local Value Master Value suhosin.apc_bug_workaround Off Off suhosin.cookie.checkraddr 0 0 suhosin.cookie.cryptdocroot On On suhosin.cookie.cryptkey [ protected ] [ protected ] suhosin.cookie.cryptlist no value no value suhosin.cookie.cryptraddr 0 0 suhosin.cookie.cryptua On On suhosin.cookie.disallow_nul 1 1 suhosin.cookie.disallow_ws 1 1 suhosin.cookie.encrypt Off Off suhosin.cookie.max_array_depth 50 50 suhosin.cookie.max_array_index_length 64 64 suhosin.cookie.max_name_length 64 64 suhosin.cookie.max_totalname_length 256 256 suhosin.cookie.max_value_length 10000 10000 suhosin.cookie.max_vars 100 100 suhosin.cookie.plainlist no value no value suhosin.coredump Off Off suhosin.disable.display_errors Off Off suhosin.executor.allow_symlink Off Off suhosin.executor.disable_emodifier Off Off suhosin.executor.disable_eval Off Off suhosin.executor.eval.blacklist no value no value suhosin.executor.eval.whitelist no value no value suhosin.executor.func.blacklist no value no value suhosin.executor.func.whitelist no value no value suhosin.executor.include.allow_writable_files On On suhosin.executor.include.blacklist no value no value suhosin.executor.include.max_traversal 0 0 suhosin.executor.include.whitelist no value no value suhosin.executor.max_depth 0 0 suhosin.filter.action no value no value suhosin.get.disallow_nul 1 1 suhosin.get.disallow_ws 0 0 suhosin.get.max_array_depth 0 0 suhosin.get.max_array_index_length 0 0 suhosin.get.max_name_length 0 0 suhosin.get.max_totalname_length 0 0 suhosin.get.max_value_length 0 0 suhosin.get.max_vars 0 0 suhosin.mail.protect 0 0 suhosin.memory_limit 0 0 suhosin.mt_srand.ignore On On suhosin.multiheader Off Off suhosin.perdir 0 0 suhosin.post.disallow_nul 1 1 suhosin.post.disallow_ws 0 0 suhosin.post.max_array_depth 0 0 suhosin.post.max_array_index_length 0 0 suhosin.post.max_name_length 0 0 suhosin.post.max_totalname_length 0 0 suhosin.post.max_value_length 0 0 suhosin.post.max_vars 0 0 suhosin.protectkey On On suhosin.request.disallow_nul 1 1 suhosin.request.disallow_ws 0 0 suhosin.request.max_array_depth 0 0 suhosin.request.max_array_index_length 0 0 suhosin.request.max_totalname_length 0 0 suhosin.request.max_value_length 0 0 suhosin.request.max_varname_length 0 0 suhosin.request.max_vars 0 0 suhosin.server.encode On On suhosin.server.strip On On suhosin.session.checkraddr 0 0 suhosin.session.cryptdocroot On On suhosin.session.cryptkey [ protected ] [ protected ] suhosin.session.cryptraddr 0 0 suhosin.session.cryptua Off Off suhosin.session.encrypt Off Off suhosin.session.max_id_length 128 128 suhosin.simulation Off Off suhosin.sql.bailout_on_error Off Off suhosin.sql.comment 0 0 suhosin.sql.multiselect 0 0 suhosin.sql.opencomment 0 0 suhosin.sql.union 0 0 suhosin.sql.user_postfix no value no value suhosin.sql.user_prefix no value no value suhosin.srand.ignore On On suhosin.stealth On On suhosin.upload.disallow_binary 0 0 suhosin.upload.disallow_elf 1 1 suhosin.upload.max_uploads 25 25 suhosin.upload.remove_binary 0 0 suhosin.upload.verification_script no value no value:confused: I included the line php_value suhosin.executor.include.whitelist "bfa://" to .htaccess The white page persist. Please get a look to our configuration data above. With kind regards Jacek |
I thought I'd start by editing the .htaccess file but I get an error. Is there a specific place in the file that it belongs?
|
not that I'm aware of
|
I know this is an old thread, but apparently still a problem. We just upgraded our server from PHP 5.2 to 5.3 and all the Atahualpa installs come up with blank pages. For now, we would like to follow the instructions to revert to 3.5.3, but the page it should be on says {download not found}
I have been searching for 3.5.3 and can't find it anywhere...how can I get a copy. As an aside, we already had to drop back to 3.6.4 from 3.6.7 due to OpenX being broke by that upgrade. Be nice to not have to keep going backwards. Thanks. |
I hope I am not leading you astray. This is how I changed the .htaccess file
I do not know if your ConfigPath would be the same...whether /home/ needs to be in there When I put in the nameofyoururl you do not add the .com suPHP_ConfigPath /home/public_html/nameofyoururl # BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase /nameofyoururl/ RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /nameofyoururl/index.php [L] </IfModule> # END WordPress I got help from the host for this |
you can find any of the old releases at http://wordpress.bytesforall.com/cat...dpress-themes/
I'm running WordPress 3,2,1 Atahualpa 3.6.7 PHP 5,3,6 and am having no problems |
Hello,
That link takes you to this page: http://wordpress.bytesforall.com/201...-353-released/ And on that page it says {download not found} I stated in my earlier mail that the link to 3.5.3 is missing so I wish you wouldn't send me back to the same place to find it still missing. Unless I am not looking in the right place, but on the 353 page it is clearly missing. Earlier I reported a problem with 3.6.7 when using openxwidget. That problem still exists so I can't use 3.6.7. I had already needed to go back to 3.6.4 due to that error. I am STILL looking for 3.5.3. Thanks |
Quote:
suPHP_ConfigPath /home/public_html/nameofyoururl That line looks wrong as it seems the path is wrong, i.e. the name of the URL would be ahead of /home, not after? Are you running your blog in the root of the domain? I am not, so I don't know what impact that would have on the URL values the other statements are looking for. I don't know if for instance they would need to be something like: RewriteRule . /domain name/directory name/index.php [L] or, because the domain name isn't in the actually root path, it is instead the "account" name which is an abbreviated version of the domain name. I am hoping there is a 3.6.8 version in the future that resolves the openX issue I reported back when 3.6.7 came out, and in the interim, I am hoping to actually be able to find 3.5.3 vs. being sent to a link where it says "download not found". Thanks! |
oh I didn't notice that. I'll send you a PM with a link to where you can get it.
|
thanks...that did it...some of the client sites were 3.4.2 and were unaffected by the PHP 5.3 upgrade so for now I left them and replaced the newer ones with the 3.5.3 and now they are all working again.
Appreciate your digging up that copy up for me... |
All times are GMT -6. The time now is 09:13 AM. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.