Hi Anatoly. > Congratz with porting TracHacks plugin. Everything looks just awesome.
Thanks :) > However, there is one major issue: > (1) I can't create new hack - the form is always redisplayed like with > preview I can confirm the issue. Checked it, and the reason for this behaviour is that at this point it seems that the logic for actually creating the hacks with the properties the user has defined in the form is completely missing. *sigh* I will take care of that in the upcoming days. I hope this is the last surprise that is expecting me with the TracHacksPlugin for a while. :) > And some minor issues: > 1. Verify email redirects to trac-hacks.org/ without 81 port - > this causes error. > http://trac-hacks.org/verify_email?token=xxx > [...] > 5. domain/port dependent links in generated TracHacks pages > http://trac-hacks.org:81/wiki/TracHacks "Create a ticket" link points to > main site Fixed (see my other mail). > http://trac-hacks.org:81/wiki/EmailProcessorMacro Download Zipped source > - the same full link [download:...] and friends are defined as pattern on InterWikiTxt. The :81 is not appended there, which explains why the links go to the main site. However, I think this is ok - it will work as expected once we switch the main site to Trac 0.11. > 2. Seems to work slow - I think that's the Genshi effect, I guess we will have to live with that at first. There are various options I see to improve the performance: 1. I will reimplement the database performance tweaks that I've applied to the Trac 0.10 instance of t-h.o. 2. I plan to restructure the WikiStart page a bit. One of the changes here will be that the hacks list is moved to a separate page that gets linked from WikiStart. This makes the start page less crowded, and as side effect it will be rendered faster. 3. Caching might help a bit. For a start, that would be caching static elements such as images, css and JavaScript files which otherwise would be delivered by Trac. Not sure about caching the page content. 4. Search engine spiders eat a nice amount of CPU time by crawling through the website and grabbing everything they can get ahold of. This includes "expensive" pages that make no sense of being cached by search engines. In front of the current main site we have some mod_security-based rules that blocked some of the most useless requests, but they don't work properly anymore (mostly because they used a private DNS-based blacklist that has been switched off). I have ideas for a plugin that would help here. I'll write a separate mail about that sometimes later (probably not before next year, however). > is there plugin to add page loading times at the bottom? I don't know of such a plugin. > 3. http://trac-hacks.org:81/blog > Not logged in. Header is not hyperlinked, shows "Recent posts (max 20) - > Browse or Archive for more". Box on the left show hyperlink - > "Archive: All posts (24)". Seems like there should be some hyperlinks. That would be a feature request for the FullBlogPlugin, I guess. From what I can tell, the behaviour shown on trac-hacks.org:81 is to be expected. But I agree that hyperlinking "Archive" and probably also "Browse" to the corresponding functionality would be a good idea. Can you please file a ticket for that? > Also there: > Error: Failed to load processor bash > No macro or processor named 'bash' found The bash processor is part of the TracPygmentsPlugin, which is required for Trac 0.10 for syntax highlighting through Pygments. As of Trac 0.11 there is native pygments support in Trac, but the implementation seems to lack the bash processor (and others) that TracPygmentsPlugin implemented. While investigating this issue, I noticed that the Trac 0.11 environment missed Pygments, dnspython, docutils, spambayes and textile, which is now fixed. Now I need to investigate how the native pygments support is expected to be used to make it render something - it seems that it's done with #!<mimetype> or something. Then I need to find wiki pages that make use of one of the TracPygmentsPlugin macros/processors and transform the macro names to the corresponding mime-types. In the end, these transformations will be applied by the script I'm using to automate the whole migration procedure. > 4. When I logout and then login again - I'm not asked for pass - it just > says "Already logged in" - could be a Chrome bug, but I doubt It at least works as expected with Firefox 3.5 and Internet Explorer 6. Not sure if the "Already logged in" message actually is something that Trac would display, it appears to be something from Chrome instead. Can someone else sched some more light on that? Christian? > 6. Can not edit description for ticket that I've created myself This is partly fixed. Trac 0.11 introduced a new permission TICKET_EDIT_DESCRIPTION, which was previously part of TICKET_MODIFY. Logged in users now have TICKET_EDIT_DESCRIPTION. For a more complete fix we'd need a policy provider that grants TICKET_EDIT_DESCRIPTION (only?) to the author of a ticket. > x. Postprocessing > http://trac-hacks.org:81/report - there can be some more useful - like > "All opened tickets by component" True, although I'd not consider that a show-stopper. Feel free to suggest other reports that might be useful. Bye, Mike _______________________________________________ th-users mailing list [email protected] https://lists.trac-hacks.org/mailman/listinfo/th-users
