Issue: Wiki not offering the WYSIWYG editor

Issue Tools
- View Changes

April 19, 2013 10:20 PM

beernuts

Junior Member

Wiki not offering the WYSIWYG editor

For some reason, our wiki is only allowing the use of the WYSIWYG editor now, even if the user's preferences say to use it.

I don't believe we have changed anything in the code recently to lead to this issue.

Issue Details

Issue Number 3033

Issue Type Bug

Project VaultWiki 3.x Series

Category Editing / Posting Articles

Status Not a Bug

Priority 3 - Loss of Functionality

Affected Version 3.0.20

Fixed Version (none)

Milestone (none)

Software DependencyvBulletin 4.x w/ ckEditor

Users able to reproduce bug 0

Users unable to reproduce bug 0

Attachments 0

Assigned Users (none)

Tags (none)

April 20, 2013 10:13 AM

pegasus

VaultWiki Team

There are two times the WYSIWYG editor cannot be used in VaultWiki:
- editing templates
- editing a headline section

This is because when you edit those, the text is only partial. Allowing the editor to try to deal with that ends up with a broken editor, or a broken page output after you save.

You should be able to use the WYSIWYG editor everywhere else. The editor may be failing to load completely. You can check your browser's Javascript Error Console for additional information if you believe this may be the case.

Reply
April 20, 2013 11:02 AM

beernuts

Junior Member

This is happening on all edits, including regular wiki articles

The javascript console has a few errors, but none of them relate to the editor.

Reply
April 20, 2013 10:49 PM

pegasus

VaultWiki Team

If I understand correctly: you still see the toolbar, the buttons still work, the text in the editor is still okay, and it still saves edits, but the link that switches to WYSIWYG mode is not present.

Reply
April 21, 2013 5:41 PM

beernuts

Junior Member

No. The problem is that we don't see the enhanced editor at all. If we edit an article, all we see is the plain text area with no WYSIWYG buttons. This was reported by a member and his settings ARE set to use the WYSIWYG editor. So then we tried it on our own profiles and also experienced the issue.

Reply
April 21, 2013 6:25 PM

pegasus

VaultWiki Team

The last time you had this issue, it had to do with your referrer whitelist settings: https://www.vaultwiki.org/issues/2703/
If the solutions in your old report don't seem to work this time, please PM me a test account that can edit the wiki.

Reply
April 22, 2013 3:34 PM

pegasus

VaultWiki Team

What are the contents of your .htaccess file for the subdomain? It looks like showwiki_proxy.php might be stealing your non-wiki requests again: https://www.vaultwiki.org/issues/2702/

Reply

April 22, 2013 3:41 PM

beernuts

Junior Member

We are running nginx and are using the configuration that you provided to us in another topic:

Code:

server {
  server_name wiki.badgerandblade.com;
  root "/home/badgerandblade/public_html/wiki";

  index index.php;
  client_max_body_size 10m;

  access_log /home/badgerandblade/_logs/wiki.access.log;
  error_log /home/badgerandblade/_logs/wiki.error.log;

  location /vault {
      rewrite ^ $uri last;
  }

  location / {
        if ($request_uri !~ \.(?:php|js|css)) {
             set $redirect_url $fastcgi_script_name;

             rewrite ^ /showwiki_proxy.php last;
        }
  }

  location ~ "^(.+\.php)($|/)" {
    fastcgi_split_path_info ^(.+\.php)(.*)$;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param SCRIPT_NAME $fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_param SERVER_NAME $host;
    fastcgi_param REDIRECT_URL $redirect_url;
    fastcgi_pass 127.0.0.1:9000;
    include        fastcgi_params;
  }
}

April 22, 2013 4:28 PM

pegasus

VaultWiki Team

Since some PHP files on the sub-domain are returning valid responses, while others are not, I'm inclined to think that some files are simply missing. What are the file contents of the root directory for the wiki sub-domain? There should be about 15 files.

Reply
April 22, 2013 5:23 PM

beernuts

Junior Member

There are 14 PHP files there.

ajax.php
index.php
showwiki.php
wiki_ajax.php
assetmanage.php
misc.php
showwiki_proxy.php
wiki_css.php
attachment.php
newattachment.php
threadtag.php
ckeditor.php
newreply.php
vw_config.php

Reply
April 22, 2013 6:37 PM
pegasus

VaultWiki Team
Have you tried re-uploading all the files in that directory from a new ZIP?

I find it a little suspicious that showwiki_proxy.php, threadtag.php, newreply.php, index.php, and wiki_css.php all work while the rest do not. Maybe the error is happening earlier than the target file call. You can also try adding this to vw_config.php:

Code:

@ini_set('display_errors', 1);
Reply
April 23, 2013 10:18 AM

beernuts

Junior Member

Just uploaded completely fresh files and enabled display_errors in vw_config.php. No errors were output and the editor still isn't showing up.

Can you clarify on what you think is suspicious? What are you saying about some files working and some not?

Reply
April 23, 2013 11:52 AM

pegasus

VaultWiki Team

What I mean is that if you visit all of the 14 PHP files you listed that exist in the directory, some of them show a vBulletin-like page (even if it's just an error message). This is the correct behavior, and it means your rewrite rules are working correctly. So it's not a rewrite issue. However, if you visit certain others of those files (such as ckeditor.php), you get absolutely nothing, just a white page and a 200 OK status.

Usually a white page is indicative of a fatal PHP error, but if display_errors isn't showing one, then the page is dying for some other reason (e.g. it's hitting an exit or die construct somewhere).

I've added a service to your Members area. If you can fill it out, I can inspect the files on your test site and try to find where this is happening.

Reply
April 23, 2013 12:26 PM

beernuts

Junior Member

Just as an update, I just now enabled APC stat because I realized that could be hiding the display_errors output and now the wiki isn't working at all. Every page request sends us back to the wiki index, so the rewrites aren't working as intended.

Nothing has changed in our nginx config. All that we did was turn APC stat on so that it would pick up the changes to the files.

I will fill out your form now.

Reply
April 23, 2013 12:53 PM

pegasus

VaultWiki Team

Whatever you did fixed it. You just needed to edit vw_config.php again after you overwrote the old one. Yes, when you use op-code caches, you need to have them configured to detect whenever you make changes to PHP files.

Reply
April 23, 2013 12:55 PM

beernuts

Junior Member

I am very confused as to what just happened, but I'm not complaining I guess.

Thanks for your help.

Reply

+ Reply

All times are GMT -4. The time now is 5:34 PM.

This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.

Learn more… Accept Remind me later

Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

Issue: Wiki not offering the WYSIWYG editor

Issue Tools