Have you tried replicating it in a clean environment with only Publisher installed? Or tried replicating it on demo.boldmimded.com? I can’t replicate the issue anywhere, so you’ll have to setup the clean EE environment with only Publisher installed to replicate it and to show it is a Publisher issue, or uninstall your addons one at a time until it starts working again to find a potential addon conflict.

Matthias, I just edited entry #93 /admin.php?/cp/publish/edit/entry/93, and Projektname, Kurzer Projektname, and Introtext field saved fine. I also see that you’re still running Publisher 2.6.3. At this point I’m not sure what else I can do b/c I’m unable to replicate it, and I tried to replicate it in your environment based on the information you provided.

Please use a tool to record a video of your screen and share a short screencast of you reproducing the bug.

Gregory, can you test something for me. Replace the getCustomField method in the Services/ChannelField.php file with the one below. Its the last method in that file. Let me know if it starts working again.

private function getCustomField($name, $return = 'field_label', $flipped = false)
    {
        $mapping = $flipped ? 'nameToField' : 'columnToField';
        $cacheKeyPrefix = 'customFields/'. $this->siteId;

        if ($field = $this->requestCache->get($cacheKeyPrefix .'/'. $mapping .'/'. $name)) {
            return $field[$return];
        }

        $customFields = array();
        /** @var \CI_DB_result $query */
        ee()->db->_reset_select();
        $query = ee()->db->get('channel_fields');

        foreach ($query->result_array() as $row) {
            $customFields[$cacheKeyPrefix .'/columnToField/field_id_'. $row['field_id']] = $row;
            $customFields[$cacheKeyPrefix .'/nameToField/'. $row['field_name']] = $row;

            $this->requestCache->set($cacheKeyPrefix .'/columnToField/field_id_'. $row['field_id'], $row);
            $this->requestCache->set($cacheKeyPrefix .'/nameToField/'. $row['field_name'], $row);
        }

        if (isset($customFields[$cacheKeyPrefix .'/'. $mapping .'/'. $name][$return])) {
            return $customFields[$cacheKeyPrefix .'/'. $mapping .'/'. $name][$return];
        }

        return null;
    }

I was experiencing some weird issues when I realized I had forgotten to run the updates in my new dev environment. Once I ran the updates the issues cleared up.

Matthias, I think your issue is you have the Drafts disabled, but its set to use Draft as the default save status, so every time it saves it is saving the draft, as evident in the DB:

https://www.dropbox.com/s/scbtekkm83hh19x/Screenshot 2017-08-28 20.40.49.png?dl=0

For now, I think if you set the Default save status setting to Open it should fix the issue.

https://www.dropbox.com/s/kmoe1ri2xvshbz7/Screenshot 2017-08-28 20.43.15.png?dl=0

I’ll add something in the future to make sure when drafts are disabled, that the default save status has to be set to open.

Greg, it looks like you have the Status option disabled too, so at first glance it does seem like a similar issue that Matthias is experiencing. Have you queried the exp_publisher_titles and exp_publisher_data tables for the entry_id that you’re testing to make sure it only has 1 row for each language and status combination. If for some reason it added a row with the incorrect status or language due to a bug, it may be querying an entirely different row when displaying the entry, thus it would be saving the data correctly now, but an orphaned/incorrect row is what is found as the first result in the query.

Glad to hear its working! I made a change for the next release to prevent this from happening. From now on if you set Disable Drafts to “yes” it will also force the default save and default view status settings to “yes”.