Loading...
 
Skip to main content

Category: MultiTiki

MultiTiki
Show subcategories objects

Name Type
jonnybradley jonny B
This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))
tracker item
5.x: images in img/trackers are not multitiki-aware as in img/wiki_up
{syntax type="tiki" editor="plain"}
images in trackers are not multitiki aware (they are all saved in img/trackers instead in the img/trackers/site1.org , etc. as for images in img/wiki_up/site1.org etc
tracker item
add param to console.php to process ALL sites from a multitiki installation at once
Right now, if you have a multitiki installation with 10 sites, and you want to rebuild the unified search index for them all, you have to run 10 times the command with the "--site=" para adapted to each case.

However, when you run setup.sh, by default setup.sh runs for all sites in a multitiki installation.

It would be nice if console.php had the chance (by default or not) to be run once for all sites in that multitiki installation at once


with some param like "--site=all":
{CODE(colors="shell")}
php console.php d:u --site=all
{CODE}
tracker item
afrog tino
This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))
tracker item
BlissTiki William
This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))
tracker item
cnd cnd
This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))
tracker item
Console commands no longer respect multitiki --site param
Since recent console.php refactoring the --site parameter is no longer respected in (for instance) the database:update command.

When running -+php console.php --site=example.com database:update+- the code in -+\Installer::buildPatchList+- builds the patch list from the default db/local.php database, not the db/example.com/local.php.

---

I think related to this, even once i've done the database:update in the browser, i cannot rebuild the index, when i do:
-+php console.php --site=example.com index:rebuild+-
i get {sign user="jonnybradley" datetime="2020-03-05T11:11:59+00:00"}
{QUOTE()}Command not available at this stage.
The database needs to be updated. Solved by: php console.php database:update{QUOTE}

---
I think this commit was the source of the regression and i'm afraid i can't fix it {gitlab id="2ee93280"} {sign user="jonnybradley" datetime="2020-03-05T11:29:44+00:00"}
tracker item
images uploaded to tracker field image do not respect multitiki paths
Images uploaded to tracker field image do not respect multitiki paths.

When you upload an image to this type of field, they go to

__img/trackers/__

When you are in a multitiki of, let's say, site1.example.com and site2.example.com, you have a folder for site1 at:

__img/trackers/site1.example.com/__

but your image files don't get uploaded there, but to the general

__img/trackers/__

And the same with all the other multitiki sites.
When you want to backup files, or migate a site to a new server, you are in trouble to know which files belong to which site from the multiki installation.

For consistency with how multitiki works, they should be uploaded to, and used from, the multitiki-aware path:

__img/trackers/site1.example.com/__
tracker item
Installation/Infrastructure
This tracker is made to help filtering and sorting the features vs categories vs options we need to tag a bug/regression/wish with.
tracker item
11.x: JS minify broken when interface in Catalan
r45953

SVN (11.0svn): May 15 2013 - REV 45953

In a multitiki install of mine, I tested an upgrade from tiki9 to tiki11, and then, switching tabs in admin panels, stopped working.

Once I disabled the js minification setting, tabs worked again.

Tried in demo.t.o/Tiki11, and it works well with or without js minification. So I was that's where the issue must come from.
---

the issue is still present in : Monday 10 June, 2013 23:33:08 CEST- REV 46275, and seems related to the Catalan interface.
Once the interface is set to Catalan, and page reloaded twice, js features stop working.

Reproduced also here in dev.t.o
tracker item
multitiki cannot be installed with tiki-install.php in trunk
I attempted to install a multitiki on subdirectories, based on trunk (Nov 29, 2008), and it failed. I installed two subdir
{CODE()}
setup.sh
www-data
www-data
site1 site2
{CODE}

and through tiki-install.php, I clicked on site1, entered details, and clicked on enter as admin and lock installer.

I couldn't see the site1 tiki
tracker item
MultiTiki doesn't work, or is impossible to configure per documentation
Read and tried the various methods in the various (sometimes conflicting) MultiTiki documentation. Could not figure out a path to success.

It appears that (although it was claimed otherwise on some other pages) that shell access is required for MultiTiki.

Questions that came about during attempt at integration:
(1) Is it possible to setup MultiTiki when one is on a hosted server (via FTP only)? If so, what is the process? I would be willing to write up the process if I could figure out how to do it.
(2) Which of the MultiTiki's is supported for TikiWiki3 ?
(3) Is there a web-based installer for setting up several tikiwikis on the same domain (but in different folders)?


How can I help vette the install process?

I would really like to setup an InterTiki + MultiTiki site as my coroporate intratnet. This would closely mimic the sub-web functionality in TWiki but allow for group wiki's to get their own distinct identity. At this point, TikiWiki is nearly more functional than TWiki, but the InterTiki/MultiTiki difficulties may be the deal breakers.
tracker item
multitiki in subdirs broken in tiki3 proposed branch due to deleting templates_c at install time
In current tiki3 proposed branch , multitiki installation is broken.
At the last step of installation through tiki-install.php, the folders inside /templates_c for each domain are deleted.

Thus, when in this step:
http://localhost/site1/tiki-install.php?nolockenter

tiki reports that
The directory '/var/www/proposed/modules/cache/learning' does not exist.
The directory '/var/www/proposed/templates_c/learning' does not exist.

And they did exist in the step before (double checked), but not just after that step.

( see http://doc.tikiwiki.org/Manual+Installation of multitikis if needed )
----
Update in Oct'09: This is a duplicated bug report with [bug2271]
Closing.
tracker item
multitiki not working if adding "?lang=ca" to tiki-install.php script => multitiki not i18n ready
multitiki not working if adding "?lang=ca" to tiki-install.php script => multitiki not i18n ready

If clicking on links at tiki-install.php, there is not language setting for the interface. And if you attempt to manually add the param, then when changing the new db settings for any child tiki install, the settings are saved in default db, not the child one.
tracker item
MultiTiki: always use master for user-related things (user messages, etc)
Say I am on dev.tw.o and I want to follow-up with a user, I end up on his tiki-user_information.php?userId=xxx __here__.

I should have a link to his page on the master.

Or else, users will end up with user-messages on various *.tikiwiki.org sites.

tracker item
Prepare for SourceForge hosted Apps
http://alexandria.wiki.sourceforge.net/Hosted+Apps

http://profiles.tikiwiki.org/SourceForge_Software_Project


((SourceForge Hosted Apps))
tracker item
tiki-edit_templates.php making bad composition of url to save a tpl to a local-theme directory
Bug for a site (e.g. drecerca) on a multitiki site (e.g. moviments.net). Using a 1.9.7cvs from a month ago (early may07, I guess)

Attempting to edit the tiki-top_bar.tpl smarty template from the web interface: http://www.moviments.net/drecerca/tiki-edit_templates.php

I got this message, when clicking on the "__save only in the theme: drecerca__" button:

{CODE()}
Warning: mkdir(templates//drecerca/styles/drecerca) [function.mkdir]: No such file or directory in /home/httpd/tiki19/tiki-edit_templates.php on line 61

You do not have permission to write the template: templates//drecerca/styles/drecerca/tiki-top_bar.tpl
{CODE}

And right place where it should attempt to save the file is:

^
templates/styles/drecerca/tiki-top_bar.tpl
^

Is this a configuration problem or just a bug?
If it's a configuration problem, the should be a tip or warning somewhere explaining how to avoid this error...
tracker item
tiki-install.php (= upgrade) fails with multitiki on subdirectories
Using tiki 2.1
I login to tiki-install.php as admin, and I see this error message:

Fatal error: Cannot redeclare extracttoppath() (previously declared in /home/httpd/tiki110/db/local.php:64) in /home/httpd/tiki110/db/local.php on line 67


We are using a multitiki in subdirectories
Example:
http://moviments.net/cursos

&

http://moviments.net/ilp

share the same multitiki installation
tracker item
Tikiwiki and Wikipedia Citation Template (XML documentation data)
Various tools are able to built a structured documentation form internet exploration.
A good example is ZOTERO.
The product can get urls, html pages content, manage a hierarchical structure, set marks etc...
The product is able to export XML files with various basic patterns :
1. Zotero RDF
2. MODS
3. RIS
4. Refer/BibIX
5. Unqualified Dublin Core RDF
6. WikiPedia Citation templates
7. BibTeX

These structured informations can be imported to a wiki structure.
he interest of Zotero RDF (but I had not the time to the Unqualified Dublin Core RDF have the advantage of containing the structure definition the link to external url and if the html page has been captured the component html page with the elementary component has images.
This model his the closest of wiki structures.

Too the Wikipedia Citation templates is close but from the url refs;

I have not found where are the text and synthesis objectives for "import" and data shared (XML files as RDF Zotero structures), and multiwiki, in 4.x and 5.x

I am interested in participating to these developments.

Best regards to everybody
tracker item
upgrading db with tiki-install.php breaks multitiki installs (removes /templates_c/ ...)
Using latest tikitrunk_svn from today (Jan. 24th, 2009)

I had a tiki site based on trunk from several weeks ago.
I added today another tiki site (using the same tiki files on server, thus using multitiki on subfolders)

Once the 2nd tiki site was up & running, I wanted to check the 1st tiki site, and it was complaining about mysql table missing, etc. So I went to run the "automatic database upgrade" ((doc:Tikiwiki 3)).
It needs to go through tiki-install.php, therefore so I did.
I had an (extracttoppath) issue, so that I attempted to go to tiki-admin.php from site one. The problem then was that tiki-index.php was complaining about:
^
The directory '/home/httpd/tikitrunk/modules/cache/javaoptics' does not exist.
The directory '/home/httpd/tikitrunk/templates_c/javaoptics' does not exist.
^

They seemed to have been deleted by the tiki-install.php script, since they were there a minute ago.
I tried also the other tiki site, and it happened the same, both folders were missing (deleted)

__Is this that tiki-install.php is not multitiki ready?__

---
duplicated bug report (by my mistake :-) ) with [bug2736]
tracker item
virtual wikis seem to share cache for groups and categories drop down lists
Hello, I'm using tikiwiki 1.9.7 and we have several virtual wikis installed at present. The problem is that the groups we get in the admin section are the groups from the virtual wiki that last made a modification to its groups. So sometimes, on the virtual wiki on which I'm admin, I see the groups of another virtual wiki, and not my own groups. The same happens for the categories. (This might also affect other domains that I haven't identified).

What seems to be happening, is that once there is a modification to groups in one of the virtual wikis, the cache is updated with that content and it seems that all virtual wikis must share the same cache... The exact cause would have to be investigated properlly as this is only an assumption deduced from the symptoms. What I do know, is that in the wiki admin section, I made sure that the cache was set to 0 (no cache), and that the individual cache checkbox was unchecked (no sure what this is supposed to do). So if this is a cache problem, it apparently occurs with a cache that you have no choice of using. Also, it can't be a browser's cache because I never go to the other virutal wikis, so there is no reason these other groups should appear in my browser suddenly.

When I do go in the groups section, the right groups are listed on the page in the section 'list of existing groups' , but in the include box of the 'add new group' section, the groups are wrong.

Well that's about it, I hope this is enough information to solve this bug. Let me know if you need specific information I haven't included in this report.

Kreugen
tracker item
Show PHP error messages