#foswiki 2017-03-10,Fri

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***OliverKrueger has left "WeeChat 1.7" [01:16]
..................................... (idle for 3h0mn)
gac410jmk0: Sorry just noticed your question. (speaker was muted)
Yes, The directory paths are fully configurable. see the {DataDir} and {PubDir} configuration keys.
configure -> general settings -> file system paths
The extension installer *should* be able to map the file locations when installing plugins. But obviously you cannot use the unzip to install. You need to use the installer
Just note that there is probably not a lot of testing happening with these alternate file system paths.
[04:16]
................. (idle for 1h24mn)
***ChanServ sets mode: +o cdot [05:43]
.................. (idle for 1h25mn)
ChanServ sets mode: +o MichaelDaum [07:08]
.................. (idle for 1h26mn)
ChanServ sets mode: +o cdot [08:34]
...................................................................... (idle for 5h46mn)
ChanServ sets mode: +o gac410 [14:20]
...... (idle for 27mn)
jmk0gac410: thanks for the response. I'm trying to implement a renderer for doxygen that will create foswiki topic files directly, and mirror the foswiki directory structure so that the output can be dropped in place. Now I just need to add an option to let users change the pub and data directory names [14:47]
gac410The Pub and Data directories are site wide though - Not something "users" would change.
If it's just one web, another approach is to symlink into the directories from pub & data
[14:48]
jmk0the directory structure mirroring is so I can drop files in place without going through the web interface. Using rsync or scp or whatever. By recreating the directory structure I don't have to do any mapping between doxygen's output and the foswiki structure [14:54]
gac410Right, I'm just saying that AFAIK you could have doxygen drop topic files into some/local/Webdir and somelocalPubdir, And from Foswiki/data ln -s path/to/some/loca//Webdir Doxygen [14:57]
jmk0true, but what I'm doing doesn't prevent that, and gives more options at the same time :) [14:57]
gac410whatever works I guess. [14:58]
jmk0heh [14:58]
gac410Just note that when installing new releases, you'll need to put back the default structure. [14:59]
jmk0what do you mean? [14:59]
gac410If you override {DataDir} and {PubDir} ... then when you extract Foswiki-upgrade-2.1.4 for ex, it will go into the original locations, and not update {DataDir}/System and {PubDir}/System
{DataDir} is the location of the path/to/foswiki/data {PubDir} is path/to/foswiki/pub for *all* webs and attachments.
[15:00]
jmk0ah, well, that's not really my problem, that's for that wiki's admin to deal with. I'm just providing the options to potentially make things easier for people to use this
all i'm doing is giving the option of manipulating the doxygen output's directory structure, it's up to the doxygen user/wiki admin to deal with the integration
[15:01]
gac410okay [15:03]
jmk0This is a batch thing, by the way, not a plugin or any sort of direct integration [15:03]
.... (idle for 16mn)
gac410Hi cdot - I've been gradually working through changing all scripturl* and puburl* macros to their fully canonical form for 2.2 Noticed a couple of things. [15:19]
cdotaye? [15:20]
gac4101 good thing - it sidesteps need for ENCODE in some cases. SCRIPTURL{viewfile}/web/topic?filename= we have to ENCODE the filename but the same {viewfile topic= filename=} handles all the encoding. [15:21]
cdotI just changed the implementation of : to use lists instead of a DIV with foswikiIndent. Simplifies quite a lot of things. May break others, though :-(
gac410: you should always list the good things last; it makes people feel better when they get th bad news first ;-)
[15:21]
gac410y. The other day I did test your branch, but it seemed to wrap all the tml together into one big text blob in the editor - no whitespace and no TML interpreting. [15:22]
cdothuh? It's working bootifully for me
not tried it on 1.1.9, though. Doubt it'll work there.
[15:22]
gac410I'll have to check it out again... but I've currently got 49 topics/templates changed with url path changes
What I observed though - I assume it's an apache config bug? I have a utf-8 attachment (content and name) viewfile works fine. Delivers it with appropriate charset header.
But if I access the file by pub/url/path ... apache delivers it as text plain, no encoding.
[15:23]
dnelI upgraded patternskin on 1.1.9, it broke a few things but I've managed to fix that. One thing left is that the permissions for unauthenticated users prevents them from seeing elements of the main web page including the log in box, is this a known issue? [15:24]
gac410Ah drats. hm Foswiki 2.x moved from DENYTOPICVIEW = <empty> to ALLOWTOPICVIEW = * for read all permissions. [15:25]
dnelchanging Set ALLOWTOPICVIEW = * to Set ALLOWTOPICVIEW = WikiGuest seems to fix it but I'm having to roll this out to a few topics [15:26]
gac410Foswiki 1.1.10 patched in backwards compatibility
ALLOWTOPICVIEW = WikiGuest will deny it from logged in users. You need to remove the ALLOWTOPICVIEW and add DENYTOPICVIEW = <empty list>
that is nothing after the =
[15:26]
dnelok, thanks, I'll try that [15:27]
gac410The code change is in commit 27029040fd5958236981f5a24095fc987dec6070 ... I'll find you a link
https://github.com/foswiki/distro/commit/27029040fd5958236981f5a24095fc987dec6070
That's a lot easier than finding and changing all the topics with ALLOW = *
[15:28]
dnelok, I'll try patching it [15:31]
gac410Actually there is a warning in the Extension topic: " Foswiki 2.0. Do not install on Foswiki version 1.x. " [15:31]
jmk0... no upgrade path? [15:32]
dnelyeah, I saw that after installing it, I couldn't find any way back from there [15:32]
gac410For a lot of the core extensions. no. [15:32]
jmk0wow [15:33]
gac410Foswiki 1.1.10 would fix it as well.
Well jmk0 The upgrade path is to upgrade foswiki.
As new features are added to core, some extensions are taking advantage of them.
We've tried to mark them as incompatible in the package info, so there is a warning in configure
[15:33]
dnelcan there not be a legacy version made available for old installs? [15:35]
gac410dnel: If you used the package installer. (From configure web, or from console shell) then it should have created a backup of the old extension in working/configure/backup
We just don't have the volunteers / person power to try to maintain obsolete versions.
1.1. 9 was released in Nov 2013. 3+ years ago. 1.1.10 was a compatibiltiy release for some critical foswiki changes, and some important perl / cpan changes.
Since then we've released a Major relese 2.0, and something like 7 patch & minor releases.
Anyway, Foswiki 1.1.10 is a very small patch release that adds some forward compatibility, and will allow foswiki to continue to work if you upgrade any perl or cpan packages.
[15:35]
dnelI'm not saying the older wikis should be maintained but something like a namespace to separate 1.0/1.1/2.0 extensions would be safer than a one-line warning about potentially breaking upgrade [15:39]
gac410y, We've looked into it. There have been a number of proposals to try to figure out how to fix this. Foswiki 3.0 will probably force our hands in that it will be a MAJOR change in core / internals.
The challenge is to figure out how to let old released code still find the extensions repository, and only show extensions that are still backwards compatibile.
There is only one namespace, and released foswiki only looks in one place. There are 300+ extensions contributed / released from various sources. Some dont' work on new foswiki code, some don't work on the old code.
[15:41]
dnelwell even if that isn't possible maybe v3 can look elsewhere for its extensions and v4 etc so that this problem can be left behind [15:44]
gac410The mistake was made back in 2008 When 1.0.0 released with a unified extensions namespace.
Since that time it's been the "elephant in the room"
We've yet to encounter the "brilliant idea" on how to fix this.
[15:45]
dnelsurely major version increases is an excuse to leave behind legacy cruft, I'm not clear why 2.0 needed to hang onto this problem if it was already known [15:47]
gac410If it's a completely new namespace, then we have to build and release 350+ extensions, many whose developers are no longer active.
probably 80% of the extensions just work.
[15:47]
dnelthat doesn't sounds particularly safe if they are largely unmaintained, not just for compatbility testing but also security [15:48]
gac410The extensions that "follow the release process" are the ones we directly manage. The others are "contributed" and it really is up to their developers .. .or volunteers to adopt them.
Many started out as "paid development" sponsored by companies who hire a consultant to write the code. But unless someone hires the consultant to modernize / extend, them, there really is not much we can do.
[15:49]
dnelfrankly if there's no interest in bringing them to a new major revision then there's no point in maintaining their availability, it's shackling the project for no real reason [15:51]
jmk0guilty [15:52]
gac410Kinda like expecting google to maintain all the android apps it distributes throug the play store. [15:52]
cdotgac410: splitting up the namespace doesn't have to be all that hard. Just needs someone to do it. [15:53]
dnelGoogle don't care whether apps continue to work on the next release, or any release for that matter. [15:53]
FoswikiBotNo Google key has been set! Set it with '!set Google google_key <key>'. [15:53]
gac410we do the best we can. Some of the more widely used extensions do get maintained. But as a "community" project, if the community won't help maintain, the handful of us cannot do everything for everybody.
The extensions are all out on github, Anyone is free to fork, fix and contribute back fixes.
Well mostly out on github. There are some that people upload without source. Those are a real challenge.
[15:54]
dnelThe important ones are maintained and available, the rest can be "try it and see" if it proves to work then bring it forward for an easier install [15:56]
gac410cdot, there have been numerous proposals, but nobody has tackled it.
And several have accumulated "concerns" which generally kills the proposal.
Anyway, Foswiki 3.0 will probably be the thing that fixes this for real. Currently NO 1.x / 2.x extensions will run without modification. Currently there is no compatibilty at all.
But that's all still a long way off.
[15:56]
dnelwell I guess it's an argument that will need to take place but imho it should because it has real UX implications
mind you, it's reminded me how many people use my wiki every day because I've had a few complaints already :)
[15:59]
gac410Trying to keep the new code working on old releases is becoming more and more of an issue. I've got a huge change pending that I have to throw 1/2 of it away because it won't be compatible.
Anyone still runing Foswiki 1.x releases is in for a WORLD of hurt if they upgrade their server to a new Perl or update CPAN modules
[16:01]
dneltrue, fortunately my server is a dinosaur, I'll get around to tackling that at some point
fwiw, that patch seems to have worked beatifully
[16:05]
cdotgac410: I confess that compatibility is no longer high on my priority list. If something doesn't work, my stock answer is now "upgrade". [16:06]
gac410y, I'm beginning to just give up. We have to start using some of the new features. Its too darn important. [16:06]
cdotBTW I want to rework the core Render.pm code to generate lists the way I'm doing it in TML2HTML [16:06]
gac410gac410 shudders [16:07]
cdotnot a big compatibility issue. Smaller and faster code. [16:07]
gac410smaller and faster is good. [16:07]
cdotAlready fixe-forwarded most of the tests. [16:07]
gac410Once I check in all the core SCRIPTURLPATH{} changes then I'll decide whether compatibility on the extensions is worth throwing out the changes I've already made to 20+ files.
The changes are part of Foswiki:Development/ContinueCanonicalSCRIPTURLDev And I still don't have a good answer settled on for "rest" and "jsonrpc"
[16:08]
FoswikiBothttps://foswiki.org/Development/ContinueCanonicalSCRIPTURLDev [ ContinueCanonicalSCRIPTURLDev ] [16:11]
gac410Where there is no web/topic in the url, but other components Plugin/Handler or Namespace/verb Not sure wtf to do yet. [16:11]
dnelthanks for your help gac410 [16:13]
***dnel has left "WeeChat 1.4" [16:14]
gac410cdot I had one brainstorm the other day. Our Foswiki::Net includes the foswiki version in it's agent string. Might be nice if the FastReport and JsonReport topics could filter the extensions list based on the agent if avaialble. [16:17]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Net [16:17]
gac410That might be one way to at least "help" the older sites avoid incompatible extensions.
And wouldn't need any code changes on the foswiki site making the request.
The agent string has changed over the years - used to be the svn rev, etc.
Currently it's 'Foswiki::Net/'  . $Foswiki::VERSION

And with that ... I'm away again.
[16:17]
GithubBot[distro] cdot pushed 3 new commits to Item14323: https://git.io/vywh8
distro/Item14323 05fd015 cdot: Item14323: convert unbulleted lists to a list type instead of a div. This uses some new classes which require a core change, so the fix won't be complete until that core change is made. However it should work even without the core change (it's a display problem only)
distro/Item14323 03ba3dd cdot: Item14323: fix last references to renamed plugin
distro/Item14323 51c1da7 cdot: Item14323: fix list types
[16:33]
***GithubBot has left [16:33]
FoswikiBothttps://foswiki.org/Tasks/Item14323 [ Item14323: Update to latest TinyMCE version ] [16:33]
....... (idle for 32mn)
GithubBot[distro] cdot pushed 1 new commit to Item14323: https://git.io/vyrU9
distro/Item14323 d557f6c cdot: Item14323: forgot a file, please delete dead button images
[17:05]
***GithubBot has left [17:05]
FoswikiBothttps://foswiki.org/Tasks/Item14323 [ Item14323: Update to latest TinyMCE version ] [17:05]
GithubBot[distro] cdot pushed 1 new commit to Item14323: https://git.io/vyrTB
distro/Item14323 ef75b01 cdot: Item14323: forgot a file, please delete dead button images
[17:07]
***GithubBot has left [17:07]
........ (idle for 36mn)
zak256 has left [17:43]
....... (idle for 30mn)
GithubBot[distro] cdot created Item14319 at fed5491 (+0 new commits): https://git.io/vyrGh [18:13]
***GithubBot has left [18:13]
FoswikiBothttps://foswiki.org/Tasks/Item14319 [ Item14319: PublishPlugin needs to encode output ] [18:13]
........ (idle for 37mn)
FoswikiOnSlack<itaki> Hello everybody. Let me remind you my support question:
<itaki> https://foswiki.org/Support/Question1861?_t=2017-03-08T19:51:38Z
[18:50]
gac410itaki, I don't know of an easy way to filter out table rows into a separate table using any of the default plugins.
cdot: MichaelDaum: Foswiki:Development/ContinueCanonicalSCRIPTURLDev was left with a syntax quandary .. how to support rest and jsonrpc.
[18:52]
FoswikiBothttps://foswiki.org/Development/ContinueCanonicalSCRIPTURLDev [ ContinueCanonicalSCRIPTURLDev ] [18:54]
gac410Maybe something like %SCRIPTURL{"rest" path="subject/verb" topic="...}% (and similar for jsonrpc) But I'm concerned about possible collisions with path= for other query params. [18:54]
FoswikiOnSlack<itaki> Thanks for your reply George. If there is no such a way, I will try it by manually which make things very difficult for us. :slightly_smiling_face: [18:55]
gac410Maybe "uripath=" or "wikipath=" ... not sure how to handle this
itaki, I really don't know if filter plugin, or some of the Table Data plugins can tackle something like that.
cdot, MichaelDaum ... any ideas on how to filter out a subset of the rows in a table . .. into a new table?
[18:55]
FoswikiOnSlack<itaki> Maybe some of the other wiki gurus have something to suggest which I can understand easily. [18:57]
***cdot has left [18:57]
.............................................. (idle for 3h45mn)
vrurgI'm at the point of creating two new caches. Damn... [22:42]
...... (idle for 29mn)
GithubBot[distro] vrurg pushed 4 new commits to Item14237: https://git.io/vyovy
distro/Item14237 14b797e Vadim Belman: Item14237: Recording of `has' attributes bug fixed....
distro/Item14237 0fcb7b8 Vadim Belman: Item14237: Compacted a debug message about a non-`has' key on a object.
distro/Item14237 f524d0f Vadim Belman: Item14237: Textual fixes.
[23:11]
***GithubBot has left [23:11]
FoswikiBothttps://foswiki.org/Tasks/Item14237 [ Item14237: Implement Development.OOConfigSpecsFormat proposal ] [23:11]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)