Wordpress On ZC [Support Thread]

[rainthebat]

In my head at the moment I have an problem when a Zen Cart/Wordpress preview page is called from the Wordpress admin area as a preview. This sounds like there is a weirdness in the way the variable $template is defined in the two programs. I am guessing that the variable is used in both lots of code? I'll have a look when I get a minute.

As long as I believe it is what I have described then I don't have too much problem in just sidestepping it.

Thanks again guys.....

Funny, it must be contagious! After I looked into the theme.php file in wp-admin, I changed the wp_redirect function name just as a test, and started to get the same error that you describe - I absolutely was not getting this error before I edited the file. To my amazement, after reverting the file to its original, the error still appears!

Well I gave up on trying to figure it out because I've settled down on a theme anyways, just wanted to see.

The $template variable is used frequently. I am not sure where it starts or what its exact powers are though, because it is used in different ways on different occasions.

[niccol]

Thanks again both Rainthebat and divavocals.

Sidestepping the problem works for me! If I have time I'll look into it deeper but probably it will turn out that other things are more interesting and useful

Thanks guys....

[DivaVocals]

Thanks again both Rainthebat and divavocals.

Sidestepping the problem works for me! If I have time I'll look into it deeper but probably it will turn out that other things are more interesting and useful

Thanks guys....

You're welcome.. sidestepping is what worked best for me too.. For example, I take my hats off to those willing to work through the quirks of getting embedded WP content to work.. I didn't have the patience! Working with the WOZ sideboxes only solved my real need to link WP to Zen.. Embedded content would be nice, but I have resigned myself to styling WP blogs to match Zen, and that's worked out well.. (WP is super easy to style..)

But one last thing.. WHAT'S THE LINK TO YOUR SITE??? all this advice, and you haven't shared!!! show us what you're doing!!!

[busyMom]

I've spent the better part of the past two days trying to track down some silliness on my in-development site (sorry, it's under xampp on my laptop, can't give you any pointers). I started pulling together a listing of the code structure which I'll try to post tomorrow. I didn't go all the way through it, but I documented the front-end summarizing the pathway from ZC index.php into WOZ. Thought this might help some of you less code-oriented users.

I do have these latest variable/constant conflicts on my mind right now, though, and I wanted to share the info before I forgot about it...

1) $title
In wp-trackback.php the variable $title obviously conflicts with a variable in ZC. I didn't bother going back to see the ZC places where it was used, but clearly it was retaining the value of one of my sidebox titles. If you click the trackback URL in a post (assuming your template displays the trackback URL), you are supposed to be redirected back to the post. I still have to debug why I'm not getting through the wp_redirect code, but I wasn't even getting to it because the $title variable wasn't empty as it should have been (I think mine had 'Reviews [more]'). I renamed the variable and all its instances in wp-trackback to $woz_title and now I'm moving on to the next section of debug. I haven't looked yet, but maybe my feed problem is similar.

2) ABSPATH
This is littered everywhere - in admin, in includes, etc. This is the same constant used in ZC and most likely isn't causing anyone any problems that haven't been gotten around already, but it occurred to me that perhaps this variable conflict is at the root of some of the issues people have had when installing the two apps in different directories. It would be a major effort to change all of your WP files to use WOZ_ABSPATH instead of ABSPATH and keep it maintained from version to version, but if you are still having issues, you might want to check if this is causing you problems.

Hope this information helps someone!
Karen

[busyMom]

2) ABSPATH
This is littered everywhere - in admin, in includes, etc.

More precisely, this should say
"This is littered everywhere - in wp-admin/*.php, in wp-includes/*.php, etc." It is in a LOT of places. I found one place, can't remember the file right now, where it is defined again and used within its own file, so I changed this to a unique constant from the WOZ_ABSPATH I changed everywhere else for testing purposes and just made that one file use MY_WOZ_ABSPATH.

I probably won't be leaving these changes in the code, but I was working my way through errors trying to get to the bottom of a dreaded 'headers already sent' problem and I wasn't sure which things would matter and which wouldn't. So for the time being, I'm removing those errors (as well as removing blank lines after the ?> in many files) from the fray to get to the big stuff and then I'll probably try restoring what I can to the released code to make it easier to maintain from level to level. If I find that there is a need to change some of these permanently, I'll post back here about it, but I think the problems are more functional than these minor changes (like the $title having a value when it should have been empty!). I have WP and ZC installed in the same directory right now, so I wouldn't be seeing some of the ABSPATH conflicts that others might experience if the constant conflict is a problem.

[busyMom]

Here are the notes I took yesterday. It's not formatted particularly pretty, but I was trying to document the hierarchical path the code took and what led to what. As I mentioned in an earlier post, it doesn't document the whole path, just from the kickoff of ZenCart's index.php to where the WOZ stuff starts running.

direction to index.php (this is the ZC version)
 ..   requires <includes/application.php> (still ZC)
       .. includes <includes/configure.php> (still ZC)
            {... bunch of defines ... }
       .. includes <includes/extra_configures/*> (still ZC)              {... includes wordpress-config.php which is where
                   the wordpress processing starts ...}
            .. includes wordpress-config.php (WOZ/WP file)
                 {... defines a bunch of constants ...}
                .. requires wp-config.php (WOZ/WP file)
                    {... defines a bunch of constants ...}
                    .. requires wp-settings.php (WOZ/WP file)
                        {... defines some constants ...}
                        {... defines a bunch of to check/setup
                              environmental settings ...}
                         .. includes wp-content/advanced-cache.php
                            if constant set (WP file)
                         .. requires wp-includes/compat.php (WP file)
                             {... provides some compatibility for old
                                   PHP, most likely not needed 
                                   anymore ...}
                          .. requires wp-includes/functions.php
                              {... defines wp utility functions ...}
                          .. requires wp-includes/classes.php (WP)
                              {... defines more wp utility functions 
                                    and classes ...}
                           .. executes require_wp_db() function 
                               {... defined in functions.php that was
                                     loaded above ...}
                            .. executes wp_cache_init() function
                            .. requires and includes a bunch of functions
                               from wp-includes (get details from file
                               directly)
                            .. defines a bunch of constants
                            .. executes force_ssl_login(FORCE_SSL_LOGIN)
                            .. requires wp-includes/vars.php
                            .. requires my-hacks.php if it exists
                            .. loads the plugins if there are any
                            .. requires wp-includes/pluggable.php
                            .. lots of other stuff!!!
                            .. includes theme's functions.php
                            .. inits everything

Sorry if there are any mistakes or not enough detail for your use. If anyone wants to build on this by adding your own level of detail (or corrections), please feel free and re-post your amended version on this thread so we can have a running summary of how the code runs from one program into the other. Things will obviously change when ZC 2.0 is ready, but at least understanding how things flow today will help those of us who want to keep using this mod, or a version of it, when it's time to migrate our platforms.

Karen

[busyMom]

Last set of tidbits for now...

There have been a few pieces of information that have been invaluable for me debugging some of the problems that I've been trying to address over the last few days, so I wanted to share my miscellaneous notes to myself. I realize a lot of these tips are WP specific, but since those of us that are here in the ZC support group are more than likely dug into ZC instead of WP, I figured I'd share it as a source of info all in one place!

Oh, first, one extra piece of information. I do not need Kiddo's fix because I use pretty permalinks. But that said, while I was trying to fix one particular rewrite in my .htaccess that was taking me for a ride, I had his fix code in there so that I could access the pages directly. Users of pretty permalinks (to understand what this is, you should refer to WP documentation, it is not a mod, it is a way of using the built-in permalinks feature) probably will not be affected by Kiddo's fix for the better or worse.

OK, now back to the intended post...

(1) Turn on WP debug via the wp-config.php file
Change this:

define('WP_DEBUG', false);

to this:

define('WP_DEBUG', true);

Remember to turn it back off when you are finished!! You don't want to run your published site like that

(2) Make LIBERAL use of echo statements in the area you are trying to debug. Depending on where you need to sprinkle them, they may cause subsequent 'header already sent' errors or other failures, but at least you'll get to see what the variable values are while the code is executing. I'm sure there are probably preferred debug environments, but I'm not familiar with them and the echo statements were QAD solutions for me.
Again, remember to comment them out when you are done, or you could write them to be dependent on the status of constant WP_DEBUG (set above) so that if you have debug on,, the echo's work and if WP_DEBUG is set to false, which is the default, the echo's don't execute.

(3) Know where your functions are. Of course your areas of concern may very well be in different parts of the code than mine, but there are some functions that get called over and over again that help you generically determine where you are and what is going on. It is especially helpful to have echo statements in this code!

wp-includes/query.php
Contains most/all of the is_xxx() functions defined, so if you can't figure out why something is being processed a certain way in WP, this is probably a good place to start. Also has a bunch of other useful functions that you might need to debug around such as have_posts(), have_comments(), etc.

wp-includes/plugin.php
Contains a bunch of functions that are used everywhere, but the one I found critical was the do_action() function. I found it very helpful to have echo statements in here to determine the actual arguments that were being passed, etc.

wp-includes/default_filters.php
Contains a one-stop-shop for at least the bulk of the WP filters and actions, if not all. This is important as the cross-reference between what filters and actions are being queued and which function is actually being executed by that action or filter. If you are unfamiliar with how this part of WP works, you will see lots of do_action('action_name') statements in the code. The 'action_name' argument refers to the name of an action, not an executable function. You need to find the associated add_action in order to see which executable function is going to run when this action runs. Filters are similar to actions.

wp-includes/pluggable.php
And last but not least... the infamous pluggable.php which seems to be mentioned in most of the dreaded 'headers already sent' errors. Ah yes, the reason is most likely because this is where the wp_redirect() function resides. And as this is the area of debug I have sitting in front of me as soon as I send this post, I do not yet have much useful information about the function; however, I do know that because this code re-posts the headers, it generates the dreaded error message when it gets here inappropriately. The important thing to note about this is that most likely your execution path is causing this code to be executed when it should not be which is why the headers are being resent. Use all of the tips above to sort out why it is getting here in the first place.

And off I go now to get my feet wet in the wp_redirect code for my own debug...

HTH Karen

[busyMom]

One more debug utility I forgot that I use...

<http://www.zen-cart.com/index.php?main_page=product_contrib_info&products_id=860>

This creates an error debug file in the ZC cache directory so that you can see all the dreaded 'headers already sent' errors and others!

HTH Karen

[BABLTD]

Hi I have been away for a bit and just finished reading through 8 months of posts!

PHEW! Things have come on a lot.

I still however have the same problem that I had 8 months ago. Site is setup and working fine except for the TITLE, KEYWORD and DESCRIPTION head tags.

I didn't want to have both sets load from WP and ZC and haven't found a way to combine them. Any help here please?

Ed

[busyMom]

Discovered a new debug assist yesterday at the bookstore! php has a function called trigger_error that allows you to post the text of a message you want (the default is that it will be a NOTICE type). If you are doing php debug and have the ZC mod installed to help you with debug (I mentioned it above, but here's the link again: <http://www.zen-cart.com/index.php?main_page=product_contrib_info&products_id=860> you can temporarily sprinkle your code with trigger_error calls instead of echo calls and you won't create a scenario where you are forcing the "headers already sent" error because of your echos. Obviously I'm still debugging the logic that is causing me grief!!