GitLab

Change-Id: Ia606ff452d027882c1f4bd9acb969c6105948207
Signed-off-by: Son Nguyen <son.nguyen@catalyst.net.nz>

Bug 1248318
Changing it from an info message to an error message (since the documentation
already calls it the "Login error message". And putting it up above the login
form instead of below.

Change-Id: I2e4906ef6010c447e5f9a00fe06bd5249020f11a

Robert Lyon authored Nov 08, 2013 and Aaron Wells committed Nov 08, 2013

Bug #1248318

This fixes a regression caused by https://reviews.mahara.org/#/c/2687



Change-Id: I0ca13766336db11c9358995fa0d0f1b9d1950da1
Signed-off-by: Robert Lyon <robertl@catalyst.net.nz>

- allow the feedback to display in a block.

Things to note:
1) The feedback block is only to display view's comments on the
view/view.php page and NOT on view/artefact.php page.

2) When in edit mode (view/blocks.php) the feedback block just
displays a 'holder' message

3) When feedback block is on page the feedback does not display at
base of page anymore and when one clicks the 'Place feedback' link the
feedback form pops up over everything similar to how editing a block
works.

4) As the feedback block only works/displays on the view page I have
not fully integrated all the stuff that feedback creates ie js/form
into the blocktype. I have left the view/view.php to do the js and
render form - and simply position the form on the page with js.

This means that if js is off the edit form will still be in it's
old place. I felt this was ok because if js is off and the form was
in the block it could mean things been too squashy if there was lots
of columns.

Change-Id: I1edaa886c5a0df1f6feb24bcdd6d8878a833d673

- also updated to view/artefact.php to allow it to repect the sortorder
chosen by the blocktype

- also got 'if artefact in view' to test the base parent artefact rather
than the subfolder artefact to see if it is allowed

Change-Id: Ic2f8c6b1673701a10751cf46c3bd9dc278fadceb
Signed-off-by: Robert Lyon <robertl@catalyst.net.nz>

Bug1247715: The mysqli driver doesn't support sending "hostname:port" but it and
the others do support setting a $db->port field manually.

Change-Id: I4f145d8a424717dbb9bed53f78cfc01f521c9dae

- the add_ok_msg, add_error_msg, and add_info_msg functions now take a
'placement' parameter. When set it will only display the message at that
location. Defaults to 'messages', the current place they are displayed.
eg:
$SESSION->add_ok_msg('hello world!', false, 'loginbox');

- to get the message to display at new location one needs to add to
the relevant template
 {dynamic}{insert_messages placement=[placement]}{/dynamic}
where [placement] = the placement parameter you are after
eg:
 {dynamic}{insert_messages placement='loginbox'}{/dynamic}

Change-Id: I202d7e3e8d86ca1c74c4488f30e6c25686ac32e0
Signed-off-by: Robert Lyon <robertl@catalyst.net.nz>

Bug 1247722: This is the latest official download from the PEAR website.
For some reason the previous version we had in place, still had the
@version substitution variable in all the files instead of the actual
version number.

Change-Id: I6eeec5d69bfb61e3914af225c62061eb5b5de3a7

Bug 1247722

Change-Id: Ic94d8af0a39bbfeb35fc902f91e05c5122ed73ed

Bug 1247722: PEAR Image_Color is already at its most recent version. This commit
helps document that fact.

Change-Id: Ib0578f8c054f4187189fd5be75327489e6afe5ec

Bug 1247722

Change-Id: I643ab44bf603ecba72e555eb0b2d9f1e91e7f623

Bug 1247722: Note that the parts of the PEAR Base System that we use, haven't actually changed
any since 1.9.2.

Change-Id: I9e5dab9287907320d73ecbbe12c9e8f828f7d92e

Bug 1246576

Change-Id: I13b6499eae6697cd0341be73c133984ba61ffc1e

Bug 1246573

Change-Id: Ibe27bb64fefb2739214f1f00877a4b4a7a5a3e11

The message was being removed due to the changes in this bug:
https://bugs.launchpad.net/mahara/+bug/1081309



Where the new message was been included in the cleanup of
old messages.

To test: add a creative commons block to page
- then try and add another. you will get the error message at top that
quickly fades away

With patch: the message should stay until you try to add block for
third time and the earlier message fades away

Change-Id: I298ba76d5f9696b3881d15868518f401236ac422
Signed-off-by: Robert Lyon <robertl@catalyst.net.nz>

- also tidied up license header to match new format used

Change-Id: I17a3c82c88e96cd02aeacf0da95d5d2d26143858
Signed-off-by: Robert Lyon <robertl@catalyst.net.nz>

- also fixed problem where the Artefact types hierarchy was not being
saved

Change-Id: I7af217cff7138aef25b6e9cf5bb9527144477da4
Signed-off-by: Robert Lyon <robertl@catalyst.net.nz>

Huzzah!

Change-Id: I22a3ef47ad3ffdc75df2ff75902a015128c23086

* changes:
  Selenium tests: Changing default speed to 500
  Selenium tests: Adding missing content/test_suite file

Bug 1236636

Change-Id: I69deb64a5113806ec89145c1213f6a1d10038d78
Signed-off-by: Aaron Wells <aaronw@catalyst.net.nz>

Change-Id: I94699c3c7c17951cd5be91221be3d00724f4a504

Without this, the tests under the content directory aren't run

Change-Id: If309f80f2ab3980af43af9d3c35a634d80514fa1

Currently we've got gitignore lines to allow an Eclipse project based
out of the /htdocs directory. For test development, I also find it handy
to set up a separate one in the /test directory.

Change-Id: Ie91b57b82940162a17c556077717b303fcb26d0c

* changes:
  Improving upgrade success messages (bug 1243525)
  Remove "TYPE=INNODB" (incompatible with MySQL 5)

On doing upgrade from v1.1 to v1.8rc

Currently if a plugin does not need upgrading it displays
a message like this:
artefact.internal   1.1.0   1.1.0   Successfully upgraded to version ?

The json returned however has message : 'Nothing to upgrade' in it

So I've altered the displaying of messages so that if nothing needs
upgrading it shows the message returned in the json.

Change-Id: I36f9b29ed9af98ee0ca77238ecb765a46c509a0b
Signed-off-by: Robert Lyon <robertl@catalyst.net.nz>

Bug 1243525: Also, since it was only used in the pre-1.1 upgrade section, it's no
longer necessary to define this at the top of upgrade.php at all

Change-Id: I907467f2ffd80844fe7f3f35eeb92a51a40ad7dd

Bug 1243525

Change-Id: I9555d15d9a08bb1e01e30e12f1ac2125535c55fa

Bug1236661: It turned out this process can take a very long time
for substantially sized Maharas, which are the ones that are most
likely to have been around since 1.4 and benefit from this. Since
we've updated the code where the orphaned pages were causing problems,
this bit is no longer strictly necessary, so it's best just to
remove it.

Change-Id: I628eb24fd7eb38a50b484df16053c55d7264d89b

Bug1234487

Change-Id: I56f1504bdc7d3f38abe254362d59998a84b62531