March 2013 - xwiki-devs@xwiki.org

[xwiki-devs] [VOTE] Retire the old WYSIWYG editor
by Sergiu Dumitriu 01 Apr '13

01 Apr '13

Hi devs, Related to the other vote about disabling the xwiki/1.0 syntax [1], I'd like to retire the old WYSIWYG editor. Although there aren't any obvious benefits, on the contrary it, removes an important feature, the advantages for doing this are: - fewer bugs (there are known bugs that we've decided not to fix since we agreed not to maintain it anymore) - less code (the .vm templates that support the editor are really crappy and I'd be very happy to get rid of them completely) - strongly encourages (developer) users to migrate to the new syntax - less non-valid, non-accessible code (standards compliance) - fewer places where XSS holes can hide (security) Personally I'd like to remove it completely, but there's also the option of putting it in a -legacy- module, still enabled in the final releases. This makes two options: A) Move the editor in a xwiki-contrib retired module B) Move the editor in xwiki-platform-legacy-web and leave it enabled My +1 goes for A. [1] http://xwiki.markmail.org/thread/6damxrncgohtk4oc -- Sergiu Dumitriu http://purl.org/net/sergiu/

5 4

[xwiki-devs] [VOTE] Disable (hide) the xwiki/1.0 syntax
by Sergiu Dumitriu 01 Apr '13

01 Apr '13

Hi devs, It's been a (long) while since the introduction of the xwiki/2.0 syntax and the new rendering engine (introduced in 1.5, declared "usable" in 1.8, set as default in 1.9). This means that since ~2008, most of the development and maintenance effort has gone into the new rendering engine and the new WYSIWYG, and this left the xwiki/1.0 syntax and old WYSIWYG editor mostly unmaintained. All the platform and XE documents have been migrated away, but there are still XEM documents using the old syntax. I'm proposing to hide the xwiki/1.0 syntax by default, so that it's no longer easy to create a new document in that syntax (unless a template is used) or to select it as the new syntax for an existing document. It will continue to be available for existing documents. +1 from me. (I guess the 72h rule won't be applied since the next 72 hours are holidays for lots of developers) -- Sergiu Dumitriu http://purl.org/net/sergiu/

7 6

[xwiki-devs] dates for revisions was updated to the date of updates
by Добровольский Евгений 29 Mar '13

29 Mar '13

Hi! I have next issue: After xwiki update from 3.2 to 4.5 all dates for revisions was updated to the date of updates. How can i fix it? I see only one way to change it in the DB: update xwikircs set xwr_date= FROM_UNIXTIME(CONVERT(substr(xwr_patch,locate('<date>', xwr_patch)+6,13),UNSIGNED INTEGER)/1000) commit is it correct? will it have impact on other objects ( keys, indexes)? mayby someone has other ideas how to fix it ..

3 4

[xwiki-devs] [BRAINSTORM] You're rewriting XWiki, you can use any technology in the world, describe it.
by Caleb James DeLisle 28 Mar '13

28 Mar '13

This is the premise, you are going to write a new XWiki. You are not bound by any backward compatibility requirements. Use any technology or combination of technologies. PHP? C++? Golang? Node.js? Java? Your call! Describe it in as much detail as possible. What frameworks will you use? What ORM? what databases? Why will it perform well? How will you get new features into the hands of users quickly? How will you avoid this: http://steve-yegge.blogspot.ca/2007/12/codes-worst-enemy.html and this: http://www.laputan.org/mud/ Think big and go wild! Thanks, Caleb

5 9

[xwiki-devs] MyPersistentLoginManager.checkValidation
by Paul Libbrecht 28 Mar '13

28 Mar '13

Hello fellow developers, So as to preserve security of our users, we do one small thing: the user-name and password (and registration info) is submitted over https. All other communication is done over http. This works well for someone connected normally to the internet. This works incorrectly for someone who is forced to use a proxy by its network conditions, e.g. hotels, wifi hotspots and mobile devices' provided networks. The reason it is the case, it the following MyPersistentLoginManager.checkValidation checks a "validation" cookie which computes a salted hash of the triple username, password, and IP. And in the cases above, the IPs are different, so the validation fails, the login is unsuccessful, the console says: > Login cookie validation hash mismatch! Cookies have been tampered with What our options? Is it true that removing IP in this validation would make the system weak as anyone stealing the cookie from another IP could become that user? Would it be as simple as finding the right header "chain end" and replace it? It seems that it would be possible. paul

2 3

[xwiki-devs] [ANN] XWiki 4.5.3 released
by Marius Dumitru Florea 27 Mar '13

27 Mar '13

The XWiki development team is proud to announce the availability of XWiki 4.5.3. This is a bugfix release. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki453 Thanks -The XWiki dev team

1 0

[xwiki-devs] [Brainstorming] Default Flavors Proposals
by Ecaterina Moraru (Valica) 25 Mar '13

25 Mar '13

Hi, I've investigated a bit what use cases could be used inside XWiki for and I've came up with: - Documentation Flavor http://markmail.org/thread/cvfzvwv6dnhkimuy - Groupware Flavor http://markmail.org/thread/mzby6ofaunrsxpun - Public WebSite Flavor http://markmail.org/thread/fgpzoxtdw2jgrrvl - Application Development Flavor http://markmail.org/thread/ion37cj7zb255j3d XWiki can be used for many things and the ones above are just the ones I've investigated recently. This mail acts like a collection of the flavors already proposed and should also gather other proposals/ideas for use cases you find interesting. One thing to have in mind is the flavor's ideas should be generic enough in order to be proposed in the sub-wiki creation process (marginal/very specific flavors should be discussed in another thread and would be of interest if we are gonna implement the Flavor Creator). The features described in the Flavors can have 5 states: - Mandatory: the feature is mandatory for the described flavor and needs to be installed; - Optional: the feature could be of interest for some sub-use cases of the described flavor. A solution to have optional features would be to customize what extensions you install in the creation process (http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custo…) or to have Disabled/Enabled states for installed extensions (http://jira.xwiki.org/browse/XWIKI-5704) - Default: the feature is bundled by default in XE. This means is tested and supported. If we are gonna create default Flavors, some features might be present just in the related flavors (like Annotations), and not by default, but right now they are default. - Extension: the feature is available as an extension. If the feature has both 'Default' and 'Extension' it means that some functionality is available by default, while additional functionality is available through extensions (one example is the Export: by default we can export in PDF, HTML, etc. but there are extensions that provide Multipage PDF Export or Export in other formats like Excel, etc.) - Custom: Custom means that the feature will have specific differences from the variant is available now. For example, in a Documentation Flavor we will need some custom templates; or the Macros categories should contain macros specially created for content creation. Each proposal describes the contained features and also provides a summary at the end, example http://incubator.myxwiki.org/xwiki/bin/view/Improvements/DocumentationFlavo… Your feedback is welcomed. Thanks, Caty

1 0

[xwiki-devs] [Brainstorming] [Flavor] Application Development Flavor
by Ecaterina Moraru (Valica) 25 Mar '13

25 Mar '13

Hi, The proposal for Application Development Flavor can be found at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/AppDevelopmentFlav… Besides being a wiki, XWiki is also an application development platform. You can build simple applications, extend the platform with custom plugins, or even build complex Web applications. There are 2 use cases related to Application Development: - one targeted to Advanced Developers. I detailed this use case because it's more complex than the other. I've made a selection of applications from our extensions repository that I considered could be of interest for developers in a web environment; - the other is targeted to Simple Users that want to create applications. For this use case, choose just the 'Mandatory' features. A simple user will always use AppWithinMinutes and we need better integration of created application to be the focus part of the sub-wiki. I encourage you to take a look at the features and give your opinion. Thanks, Caty

1 0

[xwiki-devs] [Brainstorming] [Flavor] Groupware Flavor
by Ecaterina Moraru (Valica) 25 Mar '13

25 Mar '13

Hi, The proposal for Groupware Flavor can be found at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/GroupwareFlavor Collaborative software (or groupware) is designed to help people involved in a common task achieve goals. Groupware are focused on the usage of applications and collaboration inside teams. I've tried to make a selection of application we currently have in our extensions repository. An interesting discussion would be to make proposals on applications that we currently don't have implemented, but would be vital in such a flavor. I encourage you to take a look at the features and give your opinion. Thanks, Caty

1 0

[xwiki-devs] [Brainstorming] [Flavor] Public Website Flavor
by Ecaterina Moraru (Valica) 25 Mar '13

25 Mar '13

Hi, The proposal for Public Website Flavor can be found at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/PublicWebsiteFlavor The purpose of a Public Website is to share information about a company/product and it's procedures, features, services, etc. It's the on-line presence of a company for it's targeted audience. I encourage you to take a look at the features and give your opinion. Thanks, Caty

1 0