Loading...
 
Skip to main content
Type of page »  Developers documentation
9
Page actions
PDF Print

Endangered features

Antoine de Saint Exupéry wrote:
Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away.


https://imgs.xkcd.com/comics/workflow.png

In almost each version of Tiki, some lesser used/maintained features are generally removed.

Looking in the future:

  • Features that are more or less unmaintained, or that the improvement of other features are making them redundant.
  • The goal is not to remove features. The goal is to have great functionality while keeping a maintainable code base. We must also keep in pace with the evolution of the web.
  • Sometimes, features evolve to a point where one makes the others one redundant. Migrating data in this context is always a big concern.


There is also a discussion about how to reduce disk space.

Keeping everything is clutter. It means more work for testers, for documentation, for theme work. We need to smartly manage this. After and LTS version is a great time to make larger changes, as it provides ample time for users to adapt.

Dead services or sites

(Site deaths are when sites go offline, taking their content and permalinks with them, and breaking the web accordingly - http://indiewebcamp.com/site-deaths.)

Decided to be removed

Just need person to do it and a migration path

Candidates for removals for Tiki 29

Candidates for removals for Tiki 28

Candidates for removals for Tiki 26

  • HybridAuth has millions of installations: https://packagist.org/packages/hybridauth and was added in Tiki23. It replaces functionality that was already in Tiki, so we now have duplication. An analysis should be made to confirm what should be removed, and proceed to a migration path (just docs, or with automation).
  • Menu icons
    • Check if the menu option "Folder Icon (Path and filename of closed folder icon)" actually does anything anymore and remove it if not
      • Do you mean this? https://gitlab.com/tikiwiki/tiki/-/merge_requests/1876
      • Admin pref options related to menu icons are especially confusing now that there is a new feature to assign an icon to each menu item. It isn't clear in the admin screens which options apply to the new feature and which to this (or some other?) legacy feature, so removing the old feature would solve that problem.
  • Tracker Image Field ( tracker_field_image )
    • Has been marked as deprecated since Tiki 7 (?) so it's about time! File lib/core/Tracker/Field/Image.php but also requires the writable dir img/trackers

Candidates for removals for Tiki 22 23 (post post LTS)

  • I propose to remove maketoc and continue to focus on AutoTOC, which is a way better design. AutoTOC is client-side and modern. maketoc has tons of bugs that will never be fixed. Related: TOC revamp
    • How do you print client side Auto-TOC in PDF, when it is a JS code? Wouldn't that be a case where server rendered maketoc is better for?
      Answer: mPDF generates its own TOC, with page numbers, and using the PDF format. Much better.
    • In case {maketoc} would be removed in favor of AutoToc, I find it very important to make sure that at least the following setting is added: AutoToc switched off globally and optionally switched on per page
      • Torsten: AutoToc is added on a manual basis page by page.

      an option on a per-category base would be nice aswell, but that might be too much effort?

  • Edit-Templates It was the old way of editing templates before Tiki 15 when custom templates in the theme directory was introduced. It is currently half broken because of security restrictions surrounding javascript and other security measures. In TIki 21? It Needs to be enabled through the TIki INI.

Image gallery migrate to file gallery

Was removed in Tiki23, https://gitlab.com/tikiwiki/tiki/-/commit/c6454958

Details
    • "The idea is to make the image galleries redundant, then obsolete, then nonexistant."
      What is missing in File galleries?

      Following the 2014-11-06 BBB meeting, Jyhem did a search of everything Image Galleries offer which is not in File Galleries.
      That was done on Tiki12, after checking that Image galleries are not broken in Tiki13. They are not, except the default display looks horribly old, which power users easily overcome with a custom tpl.

      • On the general images gallery configuration, configurations File galleries don't have:
        • Rankings:
        • Comments:
        • Uses Slideshow:

        • Uploaded image names must match regex:
        • Uploaded image names cannot match regex:

      • Display image information in a mouseover box:
        • No
        • Yes
        • yes, and don't display that information under the image

      • Use default max rows, images per row, thumbnails size and scale size for all galleries (set values below)
        • Max Rows per page: Default: 10
        • Images per row: Default: 6
        • Thumbnails size X: Pixels Default: 80
        • Thumbnails size Y: Pixels Default: 80
        • Default scale size:

      • Default number of comments per page:
      • Comments default ordering


      When creating a gallery, configurations File galleries don't have:

      • Max Rows per page: Default: 10
      • Images per row: Default: 6
      • Thumbnails size X: Default: 80
      • Thumbnails size Y: Default: 80

      • Fields to show during browsing the gallery:
        • XY-Size
        • Filesize
        • Gallery Image (the image used as folder image for the gallery): First image/first uploaded image/random/last image/last uploaded image
        • Available scales: ???
        • Add scaled images with bounding box of square size: ???

      • When uploading a file, what does not exist in file galleries
        • Thumbnail (optional, overrides automatic thumbnail generation):
      • Viewing image: previous/next buttons
      • images can be moved from image gal to another image gal

      • Viewing gallery:
        • Rebuild Thumbnails

      • Edit image: images can be moved from image gal to another image gal

      • I thought there was some feature allowing to turn images but I could not find it (maybe it existed in Tiki 3 and was already lost, or it's a hard to find feature, or it depends on imagemagick being installed)
    • A migration command was added to console.php in r63726 for Tiki 18.x
      This needs more testing and some documentation

Candidates for removals for Tiki 19

Post-LTS is a good time for a clean-up

  • Tiki's "powered by" icons (https://doc.tiki.org/module-poweredby) are visually retro/unreadable and informationally trivial (is it really important to say Tiki runs on PHP or uses Smarty templates?). If this "feature" is continued, maybe the display could be more like the footer area at http://wikisuite.org/Software (larger icons that highlight more significant software), or there could be a "powered by" link in the footer that directs to a page listing/describing Tiki's main libraries, etc.

Candidates for removals for Tiki 17

  • Integrator: Perhaps can be replaced by PhantomJS and CasperJS?
    Integrator should NOT be removed. We just had a UseCase, where we quite easily added a Doxygen Repository and a phdoc repository into Tiki16. I will update the docs and if and when available in Tiki I will test PhantomJS and CasperJS
    • I do not see PhantomJS and CasperJS as much implemented in Tiki (is it at all?) and sorted in a way that it could any replace Integrator. Maybe in the log run for Tiki 18 or 19, but then we need testing and documentation first!
      And it works on shared hosting out of the box
  • WebHelp: Perhaps can be replaced by mPDF export?
    • I don't see how this could be replaced by mPDF when WebHelp generates set of HTML pages and mPDF generates a PDF?
    • It should be something able to export the wiki pages structure (could be just a perspective maybe online and export to static HTML pages for offline use) to have simple layout with ToC on the left (right for RTL) side and wiki page content on the other side... essentially something like https://reasonml.github.io/docs/en/quickstart-javascript.html ( which is generated by MIT licensed Docusaurus btw: https://github.com/facebook/docusaurus )
  • Filesystem Dumps Wiki Dumps

Tiki 17 Talk

  • Is there currently a mPDF feature that can replace whelp?
    • Not exactly, but it covers the same general need of having an offline copy of the content. In PDF instead of HTML.
    • I did not (yet) find a documentation of how to print wiki structures with mPDF. Afaik that should work already, but needs at least basic documentation. If not yet implemented, it would be nice and could then imho replace whelp!?
    • it is not imho only about getting the pages as an offline format. you can have web help / manuals online too
  • I added filesystem dumps to candidate removal. Its a more buggy than whelp and has similar functionality.
    • so pref feature_dump in tiki-admin.php?page=wiki I don't use. I did a quick test. Seems to work. I don't know what should be done. Is anyone using this? Is this the right implementation?

Cleanup

This should move to own page as cleanup and remove a feature / code is not the same: Cleanup

  • Compare PluginSQL vs PluginDbReport to see if we can converge
  • File gallery HTML interface vs elFinder: can we keep just elFinder?
    • nope, -1 from me (elFinder uses obsolete jQuery-UI which should be replaced by Bootstrap imho) and the UI is highly not easy to work with 😑
    • -1 from me as well (Torsten), as in my experience elFinder is only useful at all sometimes and it is (at least for me and most of my users) usually more productive to work with the old legacy screen (especially the list-mode)
    • -1 I don't like that elFinder is so non-native-Tiki in regard to visual appearance and behavior. It's possible to override some of the elFinder CSS but not all, and takes a lot of work and adds CSS bulk. If there was a "functional CSS only" option for the elFinder source, that didn't impose its own design ideas, I'd be much happier. But this is true for a number of libraries. Also I like Tiki's admin/browse/page view options.
  • We should get rid of "Use legacy tracker insertion screen" Preference name: tracker_legacy_insert but new interface requires a few improvements (ex.: full page view)
    • We should not. I would hate to see that go and rely on the modals dialog only way (which is much more buggy, sorry). It is imho so much quicker to switch to the Edit tab than waiting to load the edit dialog and have no reference of what I have on the view tab when I need to quickly check how it shows up or want to react the comments
    • -1 from me as well (Torsten), as the legacy tracker insertion screen saves my live or keeps me productive ever so often. We are starting to use Trackers for conference booking now (after recent registration and paper management) and we need a reliable fall-back.
    • -1 I find the legacy (tabbed) insertion screen faster to use and appreciate being able to switch back and forth between tabs in some cases. The larger size for the form is also useful sometimes.
      • @luciash d' being 🧙, @Torsten Fabricius, @Gary: We can't maintain two code bases forever. So please make suggestions or point to feature requests and bugs to fix so we can remove and converge our energies.
        • @Marc Laporte I don't understand why we have two code bases for this in the first place. It should be merged into one and just an option/preference added to switch between the "open in modal" (the new way) and "open in tab" (the legacy). It shouldn' t be that complicated, should it? My suggestion is to use the more modern codebase approach and make a pref to load that edit form via ajax in the tab instead of the modal to keep the "old behavior".
  • Delete the various obsolete mods from http://svn.code.sf.net/p/tikiwiki/code/mods/trunk/
  • https://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/templates/plugins/plugin-topfriends.tpl should be at the same place as other plugin templates Was removed because it was broken, and not a good implementation
    • is it still removed and not working, or is it back, then it should indeed be in the logical right place
  • Move inline plugins from a pref to a param
  • Merge tiki-admin_security.php into tiki-admin.php?page=security
    • +1
  • smarty_function_trackerheader was really made redundant after the Tracker revamp. 2 uses remain (which do nothing) so should be removed for Tiki15
    • is that done in the meantime? We are at Tiki 18 now.
  • Redundant writable directories (as of 20.x)?
    Should be removed from setup.sh and any code
    • /dump
    • /img/wiki
    • /img/wiki_up
    • /modules/cache

Unmaintained

  • Feature home page (home_blog, etc.) and corresponding code in menu manager


Move out of mods into main code base

Perhaps distribute via Composer or Profiles?

  • Review all mods and decide what should be added to BRANCH-1-10 Tiki5
  • A solution should be found for themes
    • I find it appropriate when theme files/folders have to be uploaded to the server directly - this is organised so easily - simple copy/paste
      Theme setting/preferences that correspond to the theme files or additional Theme related content can be added by using Profiles, where the Theme provider shall make sure, that applying the themes profile would not brake existing websites.
      Theme files/folder from providers websites and the Tiki Themes Marketplace could be linked with the Tiki Profile website (or the providers profile).
      Theme providers should be encouraged to license their work in a way, that files and profiles can be republished on tiki.org in case the providers site(s) fade away


http://mods.tiki.org/

Questions

  • PCLZip: still needed?
  • Should article submissions be removed and data merged, now that we have published/unpublished status?

Candidates for renaming

  • Minichat -> Chat
  • cms (which is a legacy system name) -> articles
  • Any feature or module that includes "new" -> something more descriptive
    • modules/mod-func-calendar_new.php

Superceded (or could be with some work!)

Short term

Proposal to deprecate the following items in 5.x and fully remove in 6.0:

  • Admin: Site Ad — migrate to banners
    • Shouldn't this be a module?
  • Clean up old/replaced modules

Medium term

Long term

To merge

Idea to merge

Maybe too much work

Blog and Articles Articles in a workspace could be like current blogs

Update 2015 for Tiki 15

  • JS Calendar -> jQuery
    • Half done - need to handle time before we can totally remove it.
    • LP did it last week
  • Custom Home (totally pointless?)
  • XAJAX last update 2008-08 What should be our strategy?
    • Do we have enough of what we need in Zend Framework and jQuery?
      • Yes, i have a plan to migrate the current load_component functionality to use jQuery (jb)
  • All used code is gone, but some comments should be cleaned up for Tiki 11

Decided to keep

  • I propose to remove Draw (SVG-edit) and continue to focus on Tiki Diagram, which is way way better.
    • But drawing diagrams is not the same as drawing/editing any SVG file or drawing over a bitmap, is it? Does the Diagram thing have all the capabilities SVG Edit has? It would be a pity to loose the SVG drawing capabilities in the Cartograf e.g.
      • You can draw on a screenshot
      • 2020-02: I suspend my idea of removing SVG-edit. I have a project with a SVG-centric community coming up and we'll try to get SVG-edit a visual revamp!
  • Live Support
    • We will restart working on it once Tiki can do Realtime


Related:


History Source Comments Files 1