Please read ALL of the text so you do NOT miss anythign of what I have done :
This is what I did:
These files where created inside the Salutations theme folder ( all of them had
<?php get_header( 'question' ); ?>
<?php get_footer( 'question' ); ?> )
I copied over the code from the original files with same name minus the “template-” part. The original files ( that where already since before copied over to the Salutation Theme folder where then erased and this line where added:
<?php create_page_layout('archive-question', 'qa-layout'); // context = archive-question ?>
Where the name of the template of course where changed to fit the file names like ‘single-question’, ‘ask-question’ and so forth.
I then created a new layout that I am calling Q&A Lite with the key being your suggestion: ‘qa-layout’.
I am using same layout for all files. I fixed only in that layout a minimal header, default footer and a container with Default content in it.
This is how it looks at the moment though: http://alempijevic.com/qa-lite-plugin-not-working-properly-with-salutation-theme/
Now, what I have noticed is that the Plugin is reading somehow Both the general.css file from the plugin AND on top of that sing some of the table formating rules form teh Salutation css file.
This is a quote form the Salutation developer I found actually here in your forums from another Salutation user:
The problem is that this plugin adds it’s content by appending whatever the output is to the end of WP “the_content” function. With modern frameworks like Salutation that make use of multiple sources of content on a page by implementing custom content types, these plugins should offer better control over the output. For example, they could test the instance of “the_content” for a post type which would allow them to exclude any non-page or post types. This would keep the output from appearing in a static block such as the top tab content and the footer. Another option would be for the pulugin to offer a choice of which post types to apply the feature. It may already do this but is only testing the type for the current page, not individually testing against the exact instance of “the_content“.
Having said all that, I’m not trying to say the plugin developer did a bad job. This is a very new and unique implementation of creating WordPress content but I believe it is going to become increasingly common and the plugins will need to adapt eventually. I’m currently planning a feature that will hopefully make it possible to activate/deactivate any filter attached to “the_content” for every WP post type. This means that any plugin that attaches itself to these outputs blindly can be removed as needed for either the page, post, static block or any other custom post type you may have in use from a plugin. I’m not quite at the development stage for this feature yet but it is in the plan.
To correct the issue as you’re experiencing it. I believe you can avoid the problem completely with one simple change. Instead of creating your tab content as a static block and adding a shortcode to your tab sidebar area to reference the content, copy your tab content directly into the text widget that is in your tab sidebar. Without the use of the static block you will not experience the problem. That’s all it should take. Hopefully I’ll have some time in the next couple weeks to work on this feature to add/remove filters on “the_content” based on the post type.