When creating a new space via the sitemap app the resulting overlay does not display the "save" button - it's cut off at the bottom, so the only way to save the form is to hit "enter".

CommentFileSizeAuthor
#4 page-source.txt77.02 KBdruplicate
#2 intra_new_space_error.png143.93 KBdruplicate
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

hefox’s picture

Any JS errors? Can we get a screenshot?

druplicate’s picture

FileSize
143.93 KB

Firebug console shows no js errors. Firefox 38 on PCBSD OS.

Screen shot attached.

Note this site has a custom logo and the site slogan turned on.

mpotter’s picture

Something must be preventing javascript from running since the oa_wizard module takes that popup form and hides a bunch of stuff to give the 3 wizard steps and to resize the window. Can you try Chrome and show the Console when you refresh the page and then click Add Space?

druplicate’s picture

FileSize
77.02 KB

This site makes the home page a space. When using the site map at the "home" level, clicking "New Space" returns a page of ajax stuff (but oddly, not every time) which usually indicates a js error. Dropping into the "home" space, and clicking "New subspace" loads the modal form but partially off screen. Repeatable on different machines/OS and browsers. Server is Aegir managed at Omega8.cc using standard OA distro 2.43.

Page source file attached.

Using Chrome:

JS console:

Uncaught Error: Syntax error, unrecognized expression: #/space/1
m.error @ jquery.min.js?v=1.7.2:3
m.filter @ jquery.min.js?v=1.7.2:3
m @ jquery.min.js?v=1.7.2:3
c.querySelectorAll.m @ jquery.min.js?v=1.7.2:3
f.fn.extend.find @ jquery.min.js?v=1.7.2:3(anonymous function) @ VM1633:53
e.extend.each @ jquery.min.js?v=1.7.2:2e.fn.e.each @ jquery.min.js?v=1.7.2:2
$.fn.once @ jquery.once.js?v=1.2:55Drupal.behaviors.verticalTabs.attach @ VM1633:17
(anonymous function) @ drupal.js?nt0b90:76e.extend.each @ jquery.min.js?v=1.7.2:2
Drupal.attachBehaviors @ drupal.js?nt0b90:74
Drupal.CTools.Modal.modal_display @ modal.js?nt0b90:301
Drupal.ajax.success @ ajax.js?v=7.38:400
Drupal.ajax.ajax.options.success @ ajax.js?v=7.38:164
f.Callbacks.o @ jquery.min.js?v=1.7.2:2
f.Callbacks.p.fireWith @ jquery.min.js?v=1.7.2:2
w @ jquery.min.js?v=1.7.2:4
f.support.ajax.f.ajaxTransport.send.d @ jquery.min.js?v=1.7.2:4
hefox’s picture

Are you using drupal core as downloaded via openatrium project page? There are patches for that error (not sure if it's that specific one, but we at least did patch for similar)

druplicate’s picture

The platform is 7.38.1 (https://omega8.cc/platforms) per: https://github.com/omega8cc/7x/tree/7.x-om8 which is apparently common to all their platforms, so most likely is not the one from OA.

If there has been a patch, can you point me to it so I can close the loop with Omega8? I assume the patch will be rolled into D7 core on the next iteration anyway.

If it's not the same core I want to recommend Omega8 to use the OA version ongoing, if Aegir allows that.

hefox’s picture

Category: Bug report » Support request

You're likely missing a lot of core patches, see http://cgit.drupalcode.org/openatrium/tree/drupal-org-core.make for core patches

Also, if not using contrib modules a bundled by openatrium, may be missing that -- see oa's make files.

Please mark this as fixed if patching core/etc. fixes the issue

omega8cc’s picture

Thanks for the heads up!

We have added some OA specific patches to our D7 core fork a long time ago, but indeed some newer patches were missing.

The tricky part is that we are using the same modified core for all distros included in BOA, so we need to test all distros after adding core patches and sometimes it does conflicts and even breaks something.

We will test this with updated core now, and the only difference is that we don't use:

; Patch for fixing node_access across non-required Views relationships
projects[drupal][patch][1349080] = https://www.drupal.org/files/issues/1349080-195-d7-move-access-to-join-condition.patch

; Make node access queries more performant
projects[drupal][patch][106721] = https://www.drupal.org/files/issues/drupal-106721-optimize_node_access_queries-115.patch

Instead, we are using probably better patch, which is not compatible with 106721/115:

Issue #1349080 patch #231
https://www.drupal.org/files/issues/1349080-231-d7-move-access-to-join-condition_rework-placeholders.patch
druplicate’s picture

MIght be better to just use a custom platform for distros like OA that apply core patches often unless I'd be missing custom core patches specific to Omega8.

hefox’s picture

Did adding the patches fix the issue?

druplicate’s picture

Status: Active » Closed (fixed)

Yes, it fixed the problem.

druplicate’s picture

Status: Closed (fixed) » Active

Well, it partially fixed it.

It works at the 2nd level but not at the top level consistently - depends on the browser.

The home page of the site is a space. At that level I get a page of ajax text when clicking "New Space" with Firefox. However, if I first go to the 2nd level and then go back to the first level via the site map, it does work properly with FF. With Chromium, at the top level, the size of the modal box while loading, is a different size and the wait time is longer depending on whether I started at the top level to create a new space VS trying it after first visiting the 2nd level top space.

EDIT: I will try using the OA D7 core instead of the patched version from Omega8 and see what happens, and then report back.

druplicate’s picture

After migrating the site to a custom platform using oa-2.44 the problem went away.

But it also stopped failing on the old site running on Omega8's default oa2.43 platform.

Probably something to do with browser caching.

Anyway, it appears this is fixed now that Omega8.cc included the latest D7 core patches from OA.

druplicate’s picture

Status: Active » Closed (fixed)