Open rvanlaak opened 11 years ago
While debugging I noticed that Wordpress error_reporting is accepting way more than the Symfony error_reporting does. The Wordpress strategy is more like "hide all errors, if-crappy-code-is-working==stable" where the Symfony strategy is "show even simple notices, so coding standards are followed". Unfortunately it is no option to go and change Wordpress plugins due to updating, so changing the error_reporting is mandatory to make this bridge function correctly.
But, that still doesn't fix the shortcode problem, how to parse the plugins / shortcodes?
Another clue as result of the following code snippet:
global $shortcode_tags;
do_shortcode($content);
var_dump($shortcode_tags);
No results on the $content, it seems that Symfony / Wordpress emptied the global params (?). So the question now is, how to (re)init the shortcodes...
Damn terrible global parameters. Defining them already in the wp-config.php file is the solution for this problem. So, just add the following line to the wp-config.php will make them function again.
global $shortcode_tags;
Is there a way to implement / solve this in the Bridge?
Is this variable defined by Wordpress? If so we could put it in our bundle.
On Monday, January 21, 2013, Rvanlaak wrote:
Damn terrible global parameters. Defining them already in the wp-config.php file is the solution for this problem. So, just add the following line to the wp-config.php will make them function again.
global $shortcode_tags;
Is there a way to implement / solve this in the Bridge?
— Reply to this email directly or view it on GitHubhttps://github.com/kayue/WordpressBundle/issues/12#issuecomment-12496957.
The problem what I was facing, was that none of my plugins that were using shorttags functioned. Diving into the wordpress core-code resulted in this comment, so I found out that a global was defined.
Because Symfony actually is properly constructed, I think they overwrite all globals. Adding the snippet to any of the symfony files did not fix the problem, so I don't know or adding the global to the bundle solves the problem. What the bundle might could do is copying the wordpress globals, and restore them when Symfony is totally executed.
I think this can be fix in here: https://github.com/kayue/WordpressBundle/blob/master/Wordpress/ApiLoader.php#L94
On Mon, Jan 21, 2013 at 9:16 PM, Rvanlaak notifications@github.com wrote:
The problem what I was facing, was that none of my plugins that were using shorttags functioned. Diving into the wordpress core-code resulted in this commenthttps://github.com/kayue/WordpressBundle/issues/12#issuecomment-12494927, so I found out that a global was defined.
Because Symfony actually is properly constructed, I think they overwrite all globals. Adding the snippet to any of the symfony files did not fix the problem, so I don't know or adding the global to the bundle solves the problem. What the bundle might could do is copying the wordpress globals, and restore them when Symfony is totally executed.
— Reply to this email directly or view it on GitHubhttps://github.com/kayue/WordpressBundle/issues/12#issuecomment-12497314.
I will test your proposed fix and will commit an issue when you're right...
By using this bundle and copying the entire wordpress installation into the symfony its /web folder, making use of the Codex works. This is great, because now I can make use the best of both worlds. Unfortunately there still rest some problems. When I open a specific page (for example where I'm on a page with a contactform), I get the following notice in Symfony2 specific styling:
I tried to solve this by changing the error_handling according to the snippet in this comment.
This snippet disables the Symfony2 error reporting, resulting into functional pages. The next problem then is that all wordpress shortcodes (like [contactform var=test]) aren't parsed. A part of the solution is hidden in the following page, but I don't know exactly how yet... http://wordpress.org/support/topic/getting-short-code-to-with-get_page-function?replies=10
Any clue on how to render the [short_code] when using this bridge? Could do_shortcode() be a solution?