Error when uploading image: "Unable to fetch updated listing."

[dsat2002]

Actual behavior

Edit page -> insert image -> upload image -> "upload complete" -> "unable to fetch updated listing"

uploading the same image results in "file exists" where it does exist in ../wiki_repo/uploads/image.jpg

Expected behavior

Edit page -> insert image -> upload image -> "upload complete" -> ability to select uploaded image to insert

Steps to reproduce the behavior

upload an image

read and write permissions exist

• wiki ver 1.0.11
• node v8.9.1
• windows server 2012

[NGPixel]

This is most likely because the image parser fails to process the uploaded file. The file exists and was uploaded correctly but since it wasn't able to generate a thumbnail or read its metadata, it does not appear in the list.

Is there any error in the logs? If not, make the following modification to enable verbose logging:

• Edit file: https://github.com/Requarks/wiki/blob/master/server/libs/logger.js#L13
• Change line 13 and 16 to: level: 'verbose',
• Save and restart Wiki.js

[dsat2002]

One interesting thing to note is that when a page is open in edit mode, after the initial successful upload and error message"unable to fetch...", any other file uploaded results in 'file exists' even though it's a different file. This is reset when the current edit is discarded and edit mode is entered again.

---

This is the only error we are getting:

TeX parse error: Missing superscript or subscript argument Error: TypeError: Cannot read property '0' of null at mathjax.typeset.result (G:\Web_Services\Wiki\server\libs\markdown.js:341:37) at ReturnResult (G:\Web_Services\Wiki\node_modules\mathjax-node\lib\main.js:782:3) at Function.execute (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:243:26) at cb (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:225:59) at Object.Process (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:495:38) at Object.call (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:508:37) at Function.WAITEXECUTE (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:348:50) at cb (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:225:59) at Object.Process (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:495:38) at Object.call (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:508:37) at Function.WAITEXECUTE (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:348:50) at cb (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:225:59) at Object.Process (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:495:38) at Object.call (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:508:37) at Function.WAITEXECUTE (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:348:50) at cb (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:225:59) at Object.Process (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:495:38) at Object.call (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:508:37) at Function.WAITEXECUTE (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:348:50) at cb (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:225:59) at Function.WAITEXECUTE (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:348:50) at cb (file:///G:/Web_Services/Wiki/node_modules/mathjax/unpacked/MathJax.js:225:59)

[ZhaoTianze]

same issue.

[dsat2002]

I was able to get rid of this error by disabling mathjax in config.yml, changing: mathjax: true to mathjax: false

[gghg1989]

I fixed this issue by manually synchronizing repo folder to my git. Since I found the there is some uncommit info appears while I do git status in the repo folder: .gitignore. I sync it then reboot my wikijs docker, issue solved. Have no idea why does this happen. I wish this info can help you to figure it out.

[emptymalei]

@dsat2002 Disabling mathjax also solved my problem.

@NGPixel Would it be possible to use the mathjax frontend renderer in browser instead of node-mathjax? I would like to make the client browser work out the math instead of the server. I looked for the code about page head javascript lib path but I couldn't find it.

[felipeplets]

In my case the error was a bit different from @dsat2002:

TeX parse error: Misplaced &
Error: TypeError: Cannot read property '0' of null
    at mathjax.typeset.result (/var/wiki/server/libs/markdown.js:341:37)
    at ReturnResult (/var/wiki/node_modules/mathjax-node/lib/main.js:782:3)
    at Function.execute (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:243:26)
    at cb (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:225:59)
    at Object.Process (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:495:38)
    at Object.call (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:508:37)
    at Function.WAITEXECUTE (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:348:50)
    at cb (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:225:59)
    at Object.Process (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:495:38)
    at Object.call (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:508:37)
    at Function.WAITEXECUTE (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:348:50)
    at cb (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:225:59)
    at Object.Process (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:495:38)
    at Object.call (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:508:37)
    at Function.WAITEXECUTE (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:348:50)
    at cb (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:225:59)
    at Object.Process (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:495:38)
    at Object.call (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:508:37)
    at Function.WAITEXECUTE (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:348:50)
    at cb (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:225:59)
    at Function.WAITEXECUTE (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:348:50)
    at cb (file:///var/wiki/node_modules/mathjax/unpacked/MathJax.js:225:59)

Disabling mathjax also solved my issue.

[FeisTy-H]

Hi, is it scheduled to be fixed with a future release or disabling mathjax is the only way to retrieve information?

I have the same issue with pictures.

[Tanete]

Same issue here.

0|wiki     | TeX parse error: Missing argument for \mathcal
0|wiki     | Error: TypeError: Cannot read property '0' of null

[kopax]

same issue here. Also after this happens, I can't select a different input file.

{"ok":true,"results":[{"ok":false,"msg":"File ajt.jpg already exists."}]}

[Sebor]

I've faced with the same problem even with 'mathjax: false'. Any news about fixing?

[fpagnoux]

Same issue here

[kopax]

They do not update their code base often. Since we started using it we haven't seen any patch for all those bugs.

[NGPixel]

@kopax Development is being done on the dev branch (2.0 version), which has new commits every week. No new updates are being released for the 1.x version unless a critical bug is found.

[kopax]

I forgot you have a v2 branch, that's the reason why. Do you also have a milestone?

[sergiopuntar]

I was facing this same issue for the last few days, and disabling mathjax was no use. So I started a deeper investigation, considering what Nicolas said on his firt reply. Problem was that even after lowering the log level to verbose, I still got nothing in the logs.

So I started to dig up some code and I found that during the thumbnail generation, there is a caught exception that is not treated nor logged.

Then I added a line to at least log the exception and, not surprisiling, I got this:

2018-08-22T20:47:56.604Z - info: [AGENT]  Error: ENOENT: no such file or directory, stat '/var/wiki/data/thumbs/d131f50bdebf7b6d9336faa73040c463.png'
    at self.getImageSize.then (/var/wiki/server/libs/uploads-agent.js:204:23)
    at /var/wiki/node_modules/image-size/lib/index.js:97:7
    at /var/wiki/node_modules/image-size/lib/index.js:50:9
    at /var/wiki/node_modules/graceful-fs/graceful-fs.js:43:10
    at FSReqWrap.oncomplete (fs.js:135:15)
From previous event:
    at fs.statAsync.then (/var/wiki/server/libs/uploads-agent.js:187:43)
    at /var/wiki/node_modules/graceful-fs/polyfills.js:287:18
    at FSReqWrap.oncomplete (fs.js:153:5)
From previous event:
    at Object.processFile (/var/wiki/server/libs/uploads-agent.js:167:32)
    at Promise.map (/var/wiki/server/libs/uploads-agent.js:110:28)
    at runCallback (timers.js:789:20)
    at tryOnImmediate (timers.js:751:5)
    at processImmediate [as _immediateCallback] (timers.js:722:5)
From previous event:
    at fs.readdirAsync.then (/var/wiki/server/libs/uploads-agent.js:109:30)
    at go$readdir$cb (/var/wiki/node_modules/graceful-fs/graceful-fs.js:149:14)
    at FSReqWrap.oncomplete (fs.js:135:15)
From previous event:
    at Promise.map (/var/wiki/server/libs/uploads-agent.js:108:45)
From previous event:
    at db.UplFolder.remove.then.then (/var/wiki/server/libs/uploads-agent.js:106:26)
    at runCallback (timers.js:789:20)
    at tryOnImmediate (timers.js:751:5)
    at processImmediate [as _immediateCallback] (timers.js:722:5)
From previous event:
    at Promise.map.filter.then (/var/wiki/server/libs/uploads-agent.js:101:12)
From previous event:
    at fs.readdirAsync.then (/var/wiki/server/libs/uploads-agent.js:88:57)
    at go$readdir$cb (/var/wiki/node_modules/graceful-fs/graceful-fs.js:149:14)
    at FSReqWrap.oncomplete (fs.js:135:15)
From previous event:
    at Object.initialScan (/var/wiki/server/libs/uploads-agent.js:83:47)
    at Promise.all.then (/var/wiki/server/agent.js:198:22)
From previous event:
    at CronJob.onTick (/var/wiki/server/agent.js:193:25)
    at CronJob.fireOnTick (/var/wiki/node_modules/cron/lib/cron.js:416:22)
    at new CronJob (/var/wiki/node_modules/cron/lib/cron.js:393:28)
    at global.db.onReady.then.then (/var/wiki/server/agent.js:81:9)
    at runCallback (timers.js:789:20)
    at tryOnImmediate (timers.js:751:5)
    at processImmediate [as _immediateCallback] (timers.js:722:5)
From previous event:
    at Object.<anonymous> (/var/wiki/server/agent.js:80:4)
    at Module._compile (module.js:643:30)
    at Object.Module._extensions..js (module.js:654:10)
    at Module.load (module.js:556:32)
    at tryModuleLoad (module.js:499:12)
    at Function.Module._load (module.js:491:3)
    at Function.Module.runMain (module.js:684:10)
    at startup (bootstrap_node.js:187:16)
    at bootstrap_node.js:608:3

As I have no time to properly fix this, I just disabled the thumbnail by commenting some code, and moved on. Now the image selection window shows no thumbnails, but at least the upload works fine. Maybe I'll get back to this later and do a proper fix.

Here's the changed code

  processFile (fldName, f) {
    let self = this

    let fldPath = path.join(self._uploadsPath, fldName)
    let fPath = path.join(fldPath, f)
    let fPathObj = path.parse(fPath)
    let fUid = crypto.createHash('md5').update(fldName + '/' + f).digest('hex')

    return fs.statAsync(fPath).then((s) => {
      if (!s.isFile()) { return false }

      // Get MIME info

      let mimeInfo = fileType(readChunk.sync(fPath, 0, 262))
      if (_.isNil(mimeInfo)) {
        mimeInfo = {
          mime: mime.lookup(fPathObj.ext) || 'application/octet-stream'
        }
      }

      // Images

      if (s.size < 3145728) { // ignore files larger than 3MB
        if (_.includes(['image/png', 'image/jpeg', 'image/gif', 'image/bmp'], mimeInfo.mime)) {
          global.winston.verbose('Processing file ' + fPath + ' as image')

          return self.getImageSize(fPath).then((mImgSize) => {
            //let cacheThumbnailPath = path.parse(path.join(self._uploadsThumbsPath, fUid + '.png'))
            //let cacheThumbnailPathStr = path.format(cacheThumbnailPath)

            let mData = {
              _id: fUid,
              category: 'image',
              mime: mimeInfo.mime,
              extra: mImgSize,
              folder: 'f:' + fldName,
              filename: f,
              basename: fPathObj.name,
              filesize: s.size
            }

            global.winston.verbose('File ' + fPath + ' processing completed')

            // Generate thumbnail
            /*
            return fs.statAsync(cacheThumbnailPathStr).then((st) => {
              return st.isFile()
            }).catch((err) => { // eslint-disable-line handle-callback-err
              global.winston.error('Error processing image: ' + fPath)
              global.winston.error(err)
              return false
            }).then((thumbExists) => {
              return (thumbExists) ? mData : fs.ensureDirAsync(cacheThumbnailPath.dir).then(() => {
                return self.generateThumbnail(fPath, cacheThumbnailPathStr)
              }).return(mData)
            })
            */
            return mData
          })
        }
      } else {
        global.winston.verbose('Processing file ' + fPath + ' as binary')
      }

      // Other Files

      global.winston.verbose('File' + fPath + ' processing completed')

      return {
        _id: fUid,
        category: 'binary',
        mime: mimeInfo.mime,
        folder: 'f:' + fldName,
        filename: f,
        basename: fPathObj.name,
        filesize: s.size
      }
    })
  },

Ps.: Not sure if it´s relevant, but I run it via container over Openshift

[ghost]

Same issue here.

[JanoschDeurer]

@kopax Development is being done on the dev branch (2.0 version), which has new commits every week. No new updates are being released for the 1.x version unless a critical bug is found.

Isn't that a critical bug? I think when the image upload is not working it makes the wiki unusable.

[NGPixel]

Isn't that a critical bug? I think when the image upload is not working it makes the wiki unusable.

No as it is working fine for most people. Trying to fix all the upload issues for all possible setups would take too much time... Time that would be better spent on v2.

[JanoschDeurer]

Thank you for the fast response. We have a setup with docker-compose and your docker image. So it should be fairly standard. Should I open a new ticket that this is also not working in a basic docker-compose installation?

I would really like using wikijs, I think it has wonderful features and a really good software stack. However, this bug is making it unusable for me, also deactivating MathJax did not work for me.

[Sv3n]

Isn't that a critical bug? I think when the image upload is not working it makes the wiki unusable.

No as it is working fine for most people. Trying to fix all the upload issues for all possible setups would take too much time... Time that would be better spent on v2.

If it is working for most people, then it should be possible to determine the factor that breaks it for some.

Asking this in general to everyone: Is there a setup you know of, using docker-compose or otherwise, in which the upload feature of wikijs-v1 works? All my efforts so far have had the same (non-working) result. If so: can you please describe it, or perhaps point out the differences with my setup as shown below?

My (non-working) setup:

Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-45-generic x86_64)

root@machine:~/wikijs# docker --version
Docker version 18.06.1-ce, build e68fc7a

root@machine:~/wikijs# uname -a
Linux machine 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

root@machine:~/wikijs# docker images
REPOSITORY                                                    TAG                 IMAGE ID            CREATED             SIZE
mongo                                                         3                   b2f40c62a495        2 days ago          431MB
requarks/wiki                                                 latest              85e4f332eda3        3 months ago        315MB

root@machine:~/wikijs# cat docker-compose.yml

version: '3'
services:
  wikidb:
    image: mongo:3
    expose:
      - '27017'
    command: '--smallfiles --bind_ip ::,0.0.0.0'
    environment:
      - 'MONGO_LOG_DIR=/dev/null'
    volumes:
      - ./data/mongo:/data/db
  wikijs:
    image: 'requarks/wiki:latest'
    links:
      - wikidb
    depends_on:
      - wikidb
    ports:
      - '8089:3000'
    environment:
      WIKI_ADMIN_EMAIL: admin@example.com
    volumes:
      - /root/wikijs/cfg.yml:/var/wiki/config.yml

Wiki config, shortened: removed all commented settings, and all external auth options are disabled. Removed git-section (both with and without a valid git repo config, the upload feature behaves the same).

root@machine:~/wikijs# cat cfg.yml
# Wiki config:
# shortened: removed all commented settings, and all external auth options are disabled
# removed git-section (both with and without a valid git repo config, the upload behaviour is the same)
title: Wiki
port: 3000

paths:
  repo: ./repo
  data: ./data

uploads:
  maxImageFileSize: 30
  maxOtherFileSize: 100

lang: en

# Enable for right to left languages (e.g. arabic):
langRtl: false

public: false

sessionSecret: 1234567890abcdefghijklmnopqrstuvxyz

db: mongodb://wikidb:27017/wiki

features:
  linebreaks: false
  mathjax: false

externalLogging:
  bugsnag: false
  loggly: false
  papertrail: false
  rollbar: false
  sentry: false

theme:
  primary: indigo
  alt: blue-grey
  viewSource: all # all | write | false
  footer: blue-grey
  code:
    dark: true
    colorize: true

Text emitted on the console while running docker-compose:

console.txt

Logs from within the running container (also showing some of the files present after a failed upload (file appears in the git repo, but post-pressing seems to fail):

in_container_logs.txt Shows errors related to the not-configured git repo. My other test (with valid git config) did not show these errors, so they are unrelated to the problem at hand.

Thank you for your time! :)

[kopax]

I am worrying of what will be v2 if bugs from v1 features aren't fixed in v1. Should have been beta. When a stable release will happen?

[cypher2048]

Setting "mathjax: false" in the config file and restarting the wiki looks to have fixed the issue for me also.