alm

I’ll have to take a look at this… I didn’t ever use quick edit but it may drops and rewrites all metadata of a post or page by default.

You mean the description of the index-aggregation?! I’m planning to integrate this but it may take some time because I have to split the plugins configuration to make it a bit more clear.

You have to filter the keys instead. Don’t use the_meta but get_post_meta for the custom fields you need. See http://codex.wordpress.org/Function_Reference/get_post_meta for details. Something like that:

<ul class='post-meta'>
<li><span class='post-meta-key'>keyname:</span> <?php echo get_post_meta(the_ID(), 'keyname', true) ?></li>
<li>.....</li>
</ul>

You enter the description and keywords manually? Did you notice, that you can let the plugin set the keywords automatically? You also can set the description and a custom page title. What do you mean with overhead?

I’m planning to make settings for robots optional. This way you can alternatively use robots.txt or a specific plugin managing robots. Most plugins do not use the content for generating keywords and you always have to set meta keys and description manually. This may ask too much of ordinary authors and makes writing content confusingly. Which SEO options should it handle?

Sorry, but I don’t know what this framework actually does. If it is serving meta informations – description, keywords, title, language and canonical – then these informations are embedded twice. By the time if you can’t switch off serving meta informations in thesis you should not use the plugin with it. I’m planning to make serving metadata optional but it will take a while – after that you can use the plugin with any SEO plugin and also with thesis.

I think they should not collide in other regards. The plugin is generating keywords and description and is setting everything automatically but you can set custom information (also for title) too. It does not use simple concatention of variables – for example by using ‘%postname% – %blogname%’ as page title. This you can also do within your template and it is running much faster. But for safety purposes you should make some tests in a local installation.

Hi Matt,

thank you for your response.

I updated the paths to the javascript-files and made them relative to the admin directory. Now the files should always be found – if the directory structure of WordPress has not been changed – even if WP is not installed in root-directory.

I don’t get a javascript error in html mode but the plugin and the update-button does not work in this view… but i’ll find the problem soon.

The description should be generated automatically by default. But you need to write some text before the generation makes sense (and will appear).