Re: [pmwiki-users-de] Verschiedene Schreibweisen einer Seite, ergibt verschiedene Seiten
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, Date: Fri, 03 Jan 2014 10:43:55 +0100 From: Oliver Betz list...@gmx.net To: Pmwiki-users-de@pmichaud.com Subject: Re: [pmwiki-users-de] Verschiedene Schreibweisen einer Seite ergibt verschiedene Seiten Message-ID: i80dc9tffp5n5sbkv59j1et05unuvhv...@z1b.oliverbetz.de Content-Type: text/plain; charset=ISO-8859-1 Bernd Schatz schrieb: [...] Die Unterscheidung von WikiSeitennamen nach Groß/Gleich hat den Effekt dass oft Seiten doppelt und dreifach existieren. z.B. DatenbankAbfrage, DatenBankAbfrage, [[Datenbankabfrage]]. Bei der Gelegenheit: Das Problem geht noch weiter/tiefer: Man kann den Begriff noch unterschiedlicher schreiben, z.B. Datenbank-Abfrage, DB-Query oder Tabellenabfrage. Deshalb: Wer einen neue Eintrag anlegt, muss erst mal eine richtige Suche durchführen, ob zu dem Thema nicht schon etwas existiert. Wie schon geschrieben wurde: Ein Problem der Disziplin! Wir empfehlen unseren Nutzern auf gar keinen Fall vor anlegen eines Links zu überprüfen ob die Seite existiert, sondern: 1) Neue Informationen (z.B. Teile einer Email) per copy paste in eine entsprechende Seiten kopieren und alles bei dem der Benutzer glaubt es müsste oder könnte dokumentiert sein in ein CamelCase verwandeln. 2) Nicht über Volltextsuche Seiten suchen, sondern indem ein Link auf einer Seite angelegt wird. Falls die Seite zu einem Link existiert so gibt es einen neue Verknüpfung von zwei bisher nicht verlinkten Seiten und falls die Seite nicht existiert so sehen die andere Benutzer dass hier jemand Informationen gesucht aber nicht gefunden hat. Erfahrungsgemäß wird dem suchenden dann auch schnell geholfen. Grüße Bernd -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/Ul+AAoJEPJfz4ec1lGeCUoP/RxMueSA5iT6CQQioFpAms66 xHJyr11148nZU5o5/4Am6ipUVL2+3UdZ2KPr5LlIpe7O0q0JJimMFGIFsEjAXQxo Rp6N74/cshewWCodaWSMmrvepEfIINnqfJ/LyrMKgwyw3R3t5ZlJK1JC7qwkW7fq REdBoLt5/6QKtNTkUU3WDWtQx/HvcJ7YjePC8yu1Nw6jqJjOpPjSkUorAFzfOpJd URuj9GWy0ew1K7n3tqcfUBCL6QQliRe9aDsN2yp9z1+w2vrHZWkWAkwLw2ggBcOf By7JwFQW3D3rOTx2Axbb4MC4AgzRlGdCUnMmBQce3zRHsq5rbV88JcH+7mmvVs6E J0WxXILFuwpVf5GNLAOKXdjkb6JL0BRY2tMXZy6ZxeuzdQ2N7AsjmF8CtSJFreK9 IueSEDT/0XzxO5W4IQMB5UE6zFdOLcU8HKVmHKwTmJOsnvVNxURB9lt3zbFCx2PZ cujHEaaRYPoaFIf5NVb/uHrgiZQHVkqHhoC5S7Kr5axkoxE2acuRfWw3c+0RyHse DWXoy04cztJ5afYi8prvdzrlAnL/Ro8bCpyfo3QjlAQZ/SnXgTgQhrdnLylchs3k 0E2HgzPEj/aaVVMkZKVplWFNYw1g5nW872YAJF3iXeOaz5I29RQxyFaSeZ84veQL sO+aFjn1vZMPD81NXtYh =xsbA -END PGP SIGNATURE- ___ pmwiki-users-de mailing list pmwiki-users-de@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users-de
Re: [pmwiki-users] Proposed change to pmwiki.php: Markup_e
michael paulukonis writes: Two potential issues with moving to github: 1) the standard is to put issues onto github; this would mean there is both github issues and PITS issues. I've said this before, I do like PITS, this is the WikiWay, it is easy to demonstrate a problem, to link to the documentation etc. I have a client who migrated from Google Code to a slightly customized version of PITS, right after I revamped the interface in 2009. They are still using it daily. OTOH there may be good reasons to move to a different issue tracker. One great thing in pmwiki.org/PITS is that everything, the wiki, the documentation, the cookbook and PITS are on the same wiki, and there are a few people monitoring AllRecentChanges and, more often than I expect, help me with the mainainance and reply to questions - for which I'm really grateful. If we move to a different issue tracker, I'm afraid we'll have to put more efforts in another website to monitor. Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Mini and (:attachlist:)
Is there any way to exclude Mini's thumbnails from (:attachlist:) markup? http://www.pmwiki.org/wiki/Cookbook/Mini http://www.pmwiki.org/wiki/PmWiki/PageDirectives#attachlist (:attachlist:) does take a whitelist of extensions, but that wouldn't remove thumbs. -Michael Paulukonis http://www.xradiograph.com http://goog_2112721603Interference Patterns (a blog)http://www.xradiograph.com%5Cinterference @XraysMonaLisa https://twitter.com/XraysMonaLisa http://michaelpaulukonis.com http://www.BestAndroidResources.com Sent from somewhere in the Cloud (hearthrug, by the fender) ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Proposed change to pmwiki.php: Markup_e
I just double-checked; the Issues section of a GitHub repo can be deactivated, so the repo's reademe.md file could direct issues to go to PITS. The drawback, though, is that Issues and pull-requests are well-integrated. Another bonus of GitHub -- each repo comes with its own wiki, a CMS-engine for rapid page creation! (Which can also be turned off.) -Michael Paulukonis http://www.xradiograph.com http://goog_2112721603Interference Patterns (a blog)http://www.xradiograph.com%5Cinterference @XraysMonaLisa https://twitter.com/XraysMonaLisa http://michaelpaulukonis.com http://www.BestAndroidResources.com Sent from somewhere in the Cloud (hearthrug, by the fender) On Thu, Feb 13, 2014 at 3:23 PM, Petko Yotov 5...@5ko.fr wrote: michael paulukonis writes: Two potential issues with moving to github: 1) the standard is to put issues onto github; this would mean there is both github issues and PITS issues. I've said this before, I do like PITS, this is the WikiWay, it is easy to demonstrate a problem, to link to the documentation etc. I have a client who migrated from Google Code to a slightly customized version of PITS, right after I revamped the interface in 2009. They are still using it daily. OTOH there may be good reasons to move to a different issue tracker. One great thing in pmwiki.org/PITS is that everything, the wiki, the documentation, the cookbook and PITS are on the same wiki, and there are a few people monitoring AllRecentChanges and, more often than I expect, help me with the mainainance and reply to questions - for which I'm really grateful. If we move to a different issue tracker, I'm afraid we'll have to put more efforts in another website to monitor. Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] PmForm and uninvited links
Randy Brown writes: PmForm seems to be creating a link to my profile page, uninvited. I see this when I search for link=Profiles.MyProfile, even though I'm not aware of having created such a link. I have several pages interacting: 1. MyData: contains a pmform directive that uses MyTemplate (which is in LocalTemplates). Save updates the page text variables on this (MyData) page. 2. MyTemplate: (:include:)s other pages, which in turn may include still other pages. Note that the includes can be recursive, and can involve including an anchored section on the current page. Still, my understanding is that links are only indexed if the markup is literally on the page itself. Not exactly. When a page is saved, the markup it contains is evaluated, that is, the wikitext is converted to HTML, in order to keep track of the link targets. With a few exceptions: redirects, inclues, conditionals, pagelists, searchresults, and wikitrails are not evaluated. The (:include ...:) markups on the page are replaced with (space) before the text is evaluated, same for the other markups. That means that all other markup, including (:pmform:), will be evaluated and if it contains a WikiLink, it will be indexed. You can disable the evaluation of the (:pmform:) markup by adding this to config.php: $SaveAttrPatterns['/\\(:pmform(\\s+.*?)?:\\)/i'] = ' '; I wonder if this should be added to the pmform.php file. Petko Here are some things I've tried, each time re-saving the MyData page to refresh the link index: 1. I replace the pmform directive on MyData with a directive to simply (:include:) MyTemplate. Good result: the uninvited link disappears. 2. I return pmform to MyData, but now omit from MyTemplate the include of the other page. Good result: the uninvited link does NOT reappear. 3. I make MyData page contain only one line: (:pmform…:). Bad result: the uninvited link re-appears. 4. If I delete MyData (in case there was some kind of corruption) and try again, I get the same results. What could cause this? Randy ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Mini and (:attachlist:)
michael paulukonis writes: Is there any way to exclude Mini's thumbnails from (:attachlist:) markup? No. You may try some of the attachlist replacements or extensions in the cookbook - and if you find one that suits you, edit the page [[Site.UploadQuickReference]] and replace the (:attachlist:) markup. Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
