Changes not having any effect?

I think I am observing the same unexpected behavior.

If I add mappings OR if I change an importer parser settings, the XPath Parser Settings shown in the "standalone" import page are still the original.

I ended up having to clone the importer to inherit the new settings and mappings in the cloned importer -not pretty- flushing cache or running cron had no effect.

Here are 3 screenshots as examples:
1- The import xpath parser settings
2- going to the import page
3- the same xpath settings at the import screen, showing no updates from settings modified in screenshot 1...

Im not sure whether is meant to be like this, but if it is, it feels awkward.
Im using feeds XPath Parser 6.x.1-11 (the issue open refers to 6.x-1.9) w/ feeds 6.x beta10. Will test 'dev' versions.

Thanks for the module, inigo

Problem also occurring in 7.x-1.x-dev

This is indeed a problem. Allow me to do a brain dump.

The current behavior is that a feed source(standalone or feed node) will get the settings from the importer configuration unless they have changed the settings. This allows a single feed source to override XPath/debugging values set on an importer. The current dev provides the ability to turn off source configuration override of the parser entirely. This should help a bit. This all works pretty well for a feed node, but it is indeed odd behavior for the standalone config form.

Workarounds that come to mind at the moment:
Choose one method of configuration when using the standalone importer. Either the standalone form or importer config.
If you have overridden the values, setting them back to identical values of the importer will reset the override and allow you to configure from the importer again.

I still think having the configuration available on the standalone form is useful. Especially for debugging.
Would it make sense to turn off the config form in the importer when using the standalone option? Or, would it make more sense to try and sync the values back and forth? I'm not sure.

I just updated to 6.x-1.x-dev, but had to revert since it was B-R-O-K-E-N.

FeedsXPathParser.inc was deleted a little while back, when changes to 7.x were backported, and it appears that something is still requiring that file. I'll try to hunt that down in a separate issue.

In any case, I'm not prepared to deal with a major change to the module right now, so I'm submitting a quick patch that will work around this issue for anyone that is might want it.

I hacked the sourceFormValidate function to always return empty, which has the effect of defaulting all values.

If you're like me, needing a quick fix without any concern for source configuration overrides, this is what I did...

 public function sourceFormValidate(&$values) {

    // hacked by Darren Petersen, ServerLogic:
    // Prevent individual importers from keeping their own settings.
    // We don't want to override the master copy in any case whatsoever.
    $values = array();
    return;
    /*
    $values = $values['xpath'];
    asort($values);
    asort($this->config);
    if ($values === $this->config) {
      $values = array();
      return;
    }
    $this->configFormValidate($values);
   */
  }

I hate to hack your module needlessly, but I'm in a pinch. I'll see if I can get the dev version problem identified.

The files were rearranged. Flushing the cache should do it.

I encounter the same problem. The node import page differs from the mappings in the feed settings. I want the feed-settings as leading.

I have this issue in d7 subscribing, will test patches for d7 when provided

I confirm that the problem is still present in Feeds Xpath 7.x-1.0-beta4.
The workaround mentioned at #1 allows to overcome the problem, but is very unhandy, especially when creating or debugging the importer.

This was fixed a long time ago.

The problem you are seeing is that you have overridden the importer configuration on the source configuration page. Just disable source configuration overrides and it should match the importer settings.