professor99
Forum Replies Created
-
It really depends on server load. When notification is on the wordpress wp_mail function is invoked which can be rather slow. The attachments and featured images are updated directly after with a simple post database update. Given a setting of 3000 has been now found to be intermittent on your server I think setting it to 6000 is a safe bet for you when post notification is on.
Hi Turismo, Could you try it with post notification off and timeout at 3000. It would tell me a lot about the real nature of the problem.
To recipent98,
Try the timeout fix that seems to of worked for Turismo.
Hi Turismo. Glad to of helped. Did you try turning post notification off? Just want to eliminate possibilities.
Hi Turismo,
1. There is an option in the ‘Others’ tab ‘Show custom fields in the post’. Try that and see if it makes any difference.
2. Strange indeed. Could you try this for an attachments and then for featured image with the post notification off.
3. Then try changing the following line in wpuf-add-post.js (with and without post notification)
timeout: 3000,to
timeout: 6000,If that works change the same line in wpuf-edit-post.js
Other than adding attachments to the post and redirecting edit urls Frontend does nothing for the display of WordPress posts. It’s prime purpose is to act as a frontend version of the WordPress Dashboard.
However besides standard WordPress theme behaviour there are lots of themes and plugins that let you do this and work very nicely in conjunction with Frontend. My favourite is Site Creator Ultimate
1. This may be a bug. I haven’t look at custom fields in my development version so custom fields should behave the same as in Version 1.1. Could you provide screen shots for this?
2. Somehow we didn’t get an Ajax Response within 3 seconds. Are you talking about the “Upload Image” button or the “Submit Post” button? Do other buttons and the “Add Attachment” button work (enable Attachemnt option)? Also could you tell me what WordPress version, PHP version, and browsers you have tested this with.
Hi Turismo,
Sounds like one of your themes or plugins is changing the text style color of your Add Media button.
Frontend sets this color using the following CSS
#wpuf .wpuf-post-form a { color: #1982D1; text-decoration: none; }However the HTML which is set by TinyMCE is this
<a class="button insert-media add_media" title="Add Media" data-editor="wpuf-post-content" href="#"> <span class="wp-media-buttons-icon"></span> Add Media </a>You could try setting the CSS for one of the classes specified. I would try insert-media or add_media.
Of course you could always use FireFox Firebug or Google Chrome Developer Tools to find the source of the problem and fix it there as it probably would cause this problem wherever the editor is used.
Whoops! Typo! I accidentally included an extra ‘(‘.
Should be
if(!isset($_REQUEST['page']) or $_REQUEST['page'] !== 'members-list-configure-search') { return; }etc
I have also spoken to my server administrator and he has indicated that warnings for notices were enabled on the main php configMaybe but WordPress executes the following line at the start of wp-load.php as part of it’s bootstrap code. Note E_NOTICE is not part of this.
error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR );However turning on WP_DEBUG does enable error_reporting with the E_ALL constant in wp-includes/load.php. Unfortunately this includes E_NOTICE so we may be not on the money as this would cause our problem anyway. So back to the drawing board for the cause of the internal server error.
One thing you do need to do is to turn error logging on as the DEBUG plugin piggybacks on normal returns which in this case doesn’t happen.
Simply set WP_DEBUG_LOG and WP_DEBUG to true in wp-config.php. The log can be found in wp-content/debug.log.Anyway fix the errors and try again as the true error may be further on in the code.
Hi jonga1306,
The info you provided is more than useful and has enabled me to determine the source of your problem.
Your problem is related to both bugs and PHP error reporting.
For Members List the following lines indicate a bug
Notice: Undefined index: page in /home/mysite/public_html/wp-content/plugins/members-list/core/search.php on line 30The actual lines in code is
if($_REQUEST['page'] !== 'members-list-configure-search') { return; }This is actually run on every access to WordPress. The problem is the query variable ‘page’ is not defined on most accesses and hence the error.
The actual lines should read
if((!isset($_REQUEST['page']) or $_REQUEST['page'] !== 'members-list-configure-search') { return; }The same problem exists for this error notice as well
Notice: Undefined index: page in /home/mysite/public_html/wp-content/plugins/members-list/core/sort.php on line 30To fix change
if($_REQUEST['page'] !== 'members-list-configure-sort') { return; }to
if((!isset($_REQUEST['page']) or $_REQUEST['page'] !== 'members-list-configure-sort') { return; }For s2member the following error is self explanatory.
Notice: Undefined variable: cache_needs_updating in /home/mysite/public_html/wp-content/plugins/s2member/includes/classes/cache.inc.php on line 94Why does this happen when your HotNews theme is enabled? Well I’m guessing its to do with PHP error reporting facilities . Normally default PHP behaviour is NOT to report errors of ‘Notice’ status. However this can be changed by three methods.
1. php.ini ‘error_reporting’ setting (link1 link2)
2. Use of the PHP ini_set() function to set ‘error_reporting’
3. Use of the PHP error_reporting() function
I’m guessing that the theme developer has used option 2 or 3 for development purposes and forgotten to comment it out.
So why does this cause a crash. Well this is indicated by the following message.
WARNING: wp-includes/class-wp.php:402 - Cannot modify header information - headers already sent by (output started at /home/mysite/public_html/wp-content/plugins/members-list/core/search.php:30)This line in class-wp.php is part of the standard WordPress function send_headers(). This is normally called to send html headers for each page. However the error in search.php was already triggered before this which resulted in it sending a header previously and hence this error message.
So why is Frontend triggering this? Well it’s not just Frontend. It’s anything that uses admin-ajax.php for AJAX queries. The AJAX query results in the Member’s List error triggering (during the loading of WordPress bootstrap) and adding an error heading before AJAX adds it’s own header and hence the problem.
Hi Reticent,
Your problem may be unrelated but turning on the debug features as mentioned two posts back may provide useful information.
Also look at error reporting settings as mentioned in my next post
The post expirator problem was responded to in another post. The creator of the post expirator plugin has updated their plugin and it is no longer compatiable with Frontend. We have a couple of users investigating this to see if this can be fixed.
The PRO version has only been out a few days and Tareq is working on issues as they arise. Keep in mind that not everybody is awake 24hrs/7.
Hi Jonga1306
As you have noticed error reporting on submits in the latest development version is improved hence the different response from the last version.
I think you have definitely found the root cause of the problem. We have had problems in the past with three way situations where another plugin has combined with a theme and Frontend to cause a problem.
It’s always worth changing the theme temporarily back to a WordPress default theme when testing problems of this nature.
The current version of the theme HotNews is listed as being WordPress 3.5.1 compatiable.
The website of HotNews doesn’t list any problems of this nature but it’s worth a comment on their website just in case the author knows of the problem and already has a solution.
Causes for the 500 error are multiple. It could be that the theme is rewritting the url but there are many other possibilities.
A couple of things you could do to get more info on the error.
1. Check your server error logs
2. Enable WP_DEBUG (NB will show logs of warnings). A good plugin I use for this is Debug Bar and its sister Debug Bar ConsoleA couple of questions however.
1) What version of HotNews are you using
2) Did you try MembersList with a default WordPress theme?
3) Did the other plugins still have problems with Frontend deactivated and HotNews as theme?Thanks
TheProfessorThanks reticent. My latest development version is the best behaved version of standard Frontend released so far but there are always unknowns. I haven’t had the opportunity to put it thru the wringer to iron out the bugs on IE9 and IE10 so your work in this area is much appreciated
Cheers
TheProfessorHi Reticent98 the changes you recommended before were correct and now have been added to the development version.
Your problem with post submit I think is caused by something else. It works fine for me on PHP 5.2 & PHP5.4 and Firefox/Chrome.
I happy to help you out cause I want to make certain this works particularly for IE9 and IE10.
One thing to try is seeing if it happens on PHP5.4 with all other plugins disabled and the theme set to the default WordPress 2011 or 2012 theme.