Issue: What to do after upgrading to VW 4?

Issue Tools
- View Changes

December 15, 2014 11:00 AM

beernuts

Junior Member

What to do after upgrading to VW 4?

Some PHP Versions Can't Parse //site.com URLs

We have just upgraded to VW 4 and everything appeared to go smoothly. However, there are a couple of issues:

1. We run our Wiki on a subdomain - http://wiki.{site}.com/index.php. However, when I try to set Wiki Base URL
to wiki.{site}.com and Filename of the Wiki PHP file to index, the control panel reverts that 'index' value to 'wiki_index'. So now the navigation tab is sending users to http://wiki.{site}.com/wiki_index.php, which isn't correct.

2. VW 3 is still installed in vBulletin products. Is it safe to uninstall VW3?

3. Do we need to update any of the files on the wiki subdomain? I didn't see anything about this setup in the manual.

Issue Details

Issue Number 4104

Issue Type Bug

Project VaultWiki 4.x Series

Category General

Status Fixed

Priority 3 - Loss of Functionality

Affected Version 4.0.0 RC 5

Fixed Version 4.0.0

Milestone VaultWiki 4.0 Gold

Software DependencyvBulletin 4.x w/ ckEditor

License TypePaid

Users able to reproduce bug 0

Users unable to reproduce bug 0

Attachments 0

Assigned Users (none)

Tags (none)

December 15, 2014 2:22 PM
pegasus

VaultWiki Team
After changing any Site Config setting, Wiki Active becomes locked for several minutes while the new setting values take effect. There is no visual explanation of this currently, which can be disconcerting.

However, they will never take effect while your nginx config is missing yui-combo rules. Add the following to your main location / block, before the other wiki rules:

Code:

if ($request_uri ~ ^/yui-combo/) { rewrite ^/yui-combo/([^/]+)/(.+)$ /yui_loader.php?v=$1&f=$2 last; }

You may also have to add the yui-combo lines to your other sub-domain blocks or some Javascript functions won't work.

If this change is successful, you should start noticing AJAX activity in the Admin Panel and on some wiki pages.
Reply
December 15, 2014 2:25 PM
pegasus

VaultWiki Team
In vault/core/model/settings/vw_seo/vw.php, find:

Code:

if (file_exists(vw_Hard_Core::get_dir('deps') . '/' . $fn))

Replace with:

Code:

if ($fn AND file_exists(vw_Hard_Core::get_dir('deps') . '/' . $fn))

That should fix your ability to change the URL format.
Reply

December 15, 2014 2:51 PM

beernuts

Junior Member

Added that rule to the nginx config above the location / block but still no luck. When I view the wiki and open the console, I see several cross domain errors

Code:

Font from origin 'http://site.com' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://wiki.site.com' is therefore not allowed access.
vbulletin-core.js?v=420:1 Fire vB_XHTML_Ready
vbulletin-core.js?v=420:1 Fetch Cookie :: vbulletin_collapse (null)
wiki_index.php:1 XMLHttpRequest cannot load [url]http://site.com/vb/wiki_ajax.php?c=feed[/url]. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://wiki.site.com' is therefore not allowed access.
wiki_index.php:1 XMLHttpRequest cannot load [url]http://site.com/vb/wiki_ajax.php?c=deferred[/url]. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://wiki.site.com' is therefore not allowed access.

December 15, 2014 3:04 PM
pegasus

VaultWiki Team
In your nginx config, add the following to all your server blocks:

Code:

add_header Access-Control-Allow-Origin *.site.com;
Reply
December 15, 2014 3:09 PM

beernuts

Junior Member

Added that header, still getting the error in the console. Checked with header inspector and that header is being sent with all requests.

Reply
December 15, 2014 3:40 PM

beernuts

Junior Member

More importantly than the cross site JS is the fact that none of our articles appear to be present anymore in VW 4. I'd really like to get those working sooner than later.

Reply
December 15, 2014 3:55 PM

pegasus

VaultWiki Team

To regenerate the articles while AJAX is broken, go to Admin Panel > Maintenance/Integrity > Counters, and Rebuild URLs.

Based on my visit to your site, I have some ideas what might be causing the AJAX requests to the wrong sub-domain on your configuration, but it will take a little bit for me to work out. I'll send a PM when I think I've got it.

Reply
December 15, 2014 4:06 PM

beernuts

Junior Member

Rebuilding the URLs did not bring the content back.

When I used that feature, I got a notice (Could not find phrase 'vw_counter_cache_rebuild'.) that refreshed once and then went back to the maintenance page. But that didn't actually fix anything.

Reply
December 15, 2014 4:21 PM

beernuts

Junior Member

It looks like the old tables were called vault_{table} so vault_articles contains all of our content. But the VW 4 created vw_{table} and didn't appear to actually copy any data from the VW3 tables.

Reply
December 15, 2014 4:26 PM

pegasus

VaultWiki Team

You encountered no errors when you ran the import script (Admin Panel > Content > Import/Export)?

Reply
December 15, 2014 4:28 PM

beernuts

Junior Member

No it just instantly goes to a page that says the import was successful.

Reply
December 15, 2014 4:38 PM
pegasus

VaultWiki Team
If you run the following MySQL query, you should be able to start the import process over:

Code:

DELETE FROM vw_log WHERE logtype = 'import'

If nothing is being imported, I'm afraid I can't really know what the problem is without being able to run the importer and make changes to the importer config file myself. On the last few imports I've done, everything was copied on the first attempt and I didn't need to do anything else. If the importer isn't working on your configuration, we can waive the service fee and do it through Ticket Support.

The importer does rely on Javascript to run without the user clicking Next all the time. It's possible that if cross-domain Javascript has been an issue, that this is contributing the importer not actually importing anything.
Reply
December 15, 2014 4:43 PM

beernuts

Junior Member

Cleared the table, ran the import, same thing.

If you send me your public key via PM, I can get you set up on the servers and admincp.

Reply
December 15, 2014 7:09 PM

pegasus

VaultWiki Team

This appears to be fixed now.

It seems your version of PHP was not able to parse URLs starting with //, which VaultWiki uses for un-enforced HTTPS. This resulted in PHP saying the path was invalid so it wasn't being used for Javascript functions. I created a workaround, and the importer is currently running.

I will keep you informed of its progress.

Reply
December 16, 2014 9:16 AM
pegasus

VaultWiki Team
If you still have the following in your nginx config:

Code:

if ($request_uri !~ \.(?:php|js|css)) {

Please change it to the following:

Code:

if ($request_uri !~ \.(?:php|js|css|png|jpg|gif|woff)) {

Then you should be all set.

Also I'm not seeing the Cross-Origin header anymore:

Code:

add_header Access-Control-Allow-Origin *.site.com;

This should be present in the wiki.site.com block, as well as your standard site.com block. Both sides need to know they are allowed to communicate.
Reply

+ Reply

All times are GMT -4. The time now is 1:56 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: What to do after upgrading to VW 4?

Issue Tools