WordPress.org

Making WordPress.org

Opened 3 months ago

Last modified 12 days ago

#3526 new task

Fix any brokenness in Trac 1.2.2

Reported by: dd32 Owned by:
Milestone: Priority: high
Component: Trac Keywords:
Cc:

Description (last modified by dd32)

As part of the final items of the datacenter move, SVN and Trac are being brought over.

The upgrade of Trac from 1.something to 1.2.2 has revealed a few bugs, lets track them here.


Known issues:

from @dd32

A bunch of the JS/CSS files are updated, and Trac doesn't have cache-busters (https://trac.edgewall.org/ticket/9936 - seven years and counting) so we'll need to update and force-clear caches once all Trac's are updated.


Should be fixed:

https://wordpress.slack.com/archives/C02RQBYUG/p1521424715000009

plus attached screenshots are not showing in ticket, only when you click on the image link

https://wordpress.slack.com/archives/C02QB8GMM/p1521410697000088

The BuddyPress trac is showing invalid data for the two most recent commits, though a SVN checkout has the svn log working correctly. Easy to see on https://buddypress.trac.wordpress.org/log (11898, 11899). Can anyone help?

https://wordpress.slack.com/archives/C02RQBYUG/p1521424003000027

The dropdown for the Keywords is gone for both BP and bbPress tracs and one needs to manually add the keywords plus the Add comment textbox is now under the Action fieldset

Should be fixed pending [6893], [6895], and [6896]

https://wordpress.slack.com/archives/C02RQBYUG/p1521440267000037

the Preview box that shows up when you create a new ticket or Add comment is missing/gone.

Should be fixed pending [6893], [6895], and [6896]

https://wordpress.slack.com/archives/C02RQBYUG/p1521424454000022

#buddypress-firehose does not show new comment in existing ticket

Change History (60)

#1 @dd32
3 months ago

In 6895:

Trac: Stub out some compat-functions to wp-trac.js until the CDN trac.js is available.
This avoids the JS Errors, but some functionalities may not work.

See #3526.

#2 @dd32
3 months ago

In 6896:

Trac: Bump scripts_version following r6895.

See #3526

#3 @dd32
3 months ago

Shifting known issues to ticket description instead.

Last edited 3 months ago by dd32 (previous) (diff)

This ticket was mentioned in Slack in #meta by dd32. View the logs.


3 months ago

#5 @dd32
3 months ago

  • Description modified (diff)

#6 @dd32
3 months ago

  • Description modified (diff)

This ticket was mentioned in Slack in #buddypress by netweb. View the logs.


3 months ago

#8 @dd32
3 months ago

  • Description modified (diff)

https://buddypress.trac.wordpress.org/log has been fixed, commits should flow to tickets now.

#9 @dd32
3 months ago

  • Description modified (diff)

Looks like the JS fixes probably fixed uploaded attachments not auto-expanding too.

#10 @DJPaul
3 months ago

On buddypress.trac, i'm getting the follow JS console message when viewing an existing ticket while authenticated:

TypeError: $(".trac-disable").disableSubmit is not a function. (In '$(".trac-disable").disableSubmit(".trac-disable-determinant")', '$(".trac-disable").disableSubmit' is undefined)

Last edited 3 months ago by DJPaul (previous) (diff)

This ticket was mentioned in Slack in #bbpress by netweb. View the logs.


3 months ago

#12 @netweb
3 months ago

Fixed Known issues:
https://wordpress.slack.com/archives/C02RQBYSJ/p1521967842000073

New tickets not appearing in #bbpress, #bbpress-firehose, or #bbpress-newtickets


Last edited 2 months ago by netweb (previous) (diff)

#13 follow-ups: @ocean90
2 months ago

Last edited 2 months ago by ocean90 (previous) (diff)

#14 @ocean90
2 months ago

In 7064:

Slack/Trac: Add support for attachment notification mails.

See #3526.

#15 @dd32
2 months ago

  • Description modified (diff)

#16 @dd32
2 months ago

In 7065:

Trac: Don't double up the comment deletion buttons.

This needs a follow up once all Tracs are migrated to remove this block of code / the extra template changes.

See #3526.

#17 in reply to: ↑ 13 @dd32
2 months ago

Replying to ocean90:

This is caused by Trac containing this in it's preview HTML:

jQuery.loadStyleSheet("https://s.w.org/style/trac/common/css/trac.css", "text/css");

Using the old Trac JS causes trac.css to get reloaded after wp-trac.css.

Once the new trac.js is in use, it'll be fixed as loadStyleSheet() now contains some logic not to reload the stylesheet if it's already loaded into the DOM.

#18 in reply to: ↑ 13 ; follow-up: @dd32
2 months ago

Replying to ocean90:

  • The order of the "Modify Ticket" and "Add Comment" is different. It was "Add Comment" - "Modify Ticket" previously.

Do we care about that order change? it doesn't seem to be a real issue to me

#19 follow-up: @dd32
2 months ago

In 7066:

Trac: Bump scripts_version following [7065].

See #3526.

#20 in reply to: ↑ 19 @dd32
2 months ago

Replying to dd32:

In 7066:

Trac: Bump scripts_version following [7065].

See #3526.

Bumping scripts_version is no longer enough to trigger a Trac Template refresh too.

#21 @ocean90
2 months ago

#3565 was marked as a duplicate.

#22 @ocean90
2 months ago

#3564 was marked as a duplicate.

#23 in reply to: ↑ 18 ; follow-up: @SergeyBiryukov
2 months ago

Replying to dd32:

Replying to ocean90:

The order of the "Modify Ticket" and "Add Comment" is different. It was "Add Comment" - "Modify Ticket" previously.

Do we care about that order change? it doesn't seem to be a real issue to me

The previous order was helpful to avoid unintentionally editing the ticket description instead of writing a comment. Adding a comment is a much more common action than editing the ticket, so it should come first.

The current order causes some confusion each time I'm leaving a comment, and could probably cause even more confusion for new contributors.

Last edited 2 months ago by SergeyBiryukov (previous) (diff)

#24 in reply to: ↑ 23 ; follow-up: @dd32
2 months ago

Replying to SergeyBiryukov:

Replying to dd32:

Replying to ocean90:

The order of the "Modify Ticket" and "Add Comment" is different. It was "Add Comment" - "Modify Ticket" previously.

Do we care about that order change? it doesn't seem to be a real issue to me

The previous order was helpful to avoid unintentionally editing the ticket description instead of writing a comment. Adding a comment is a much more common action than editing the ticket, so it should come first.
The current order causes some confusion each time I'm leaving a comment, and could probably cause even more confusion for new contributors.

Although I find it hard to believe that someone would accidentally edit the ticket description once used to the UI, and it's worth noting this is specifically for Bug Gardeners as regular users can't edit ticket descriptions, we might as well flip them back around then.

#25 in reply to: ↑ 24 @SergeyBiryukov
2 months ago

Replying to dd32:

Although I find it hard to believe that someone would accidentally edit the ticket description once used to the UI

I remember this being an occasional issue over the years, the sections were flipped for a reason :) It was one of the things that made Trac more user-friendly for Bug Gardeners.

Last edited 2 months ago by SergeyBiryukov (previous) (diff)

#26 follow-up: @ocean90
2 months ago

In 7078:

Trac: Append a version string to Trac's JavaScript/CSS files hosted on the w.org CDN.

For testing purposes limited to meta.trac for now.

See #3526.

#27 in reply to: ↑ 26 @dd32
2 months ago

Replying to ocean90:

In 7078:

Trac: Append a version string to Trac's JavaScript/CSS files hosted on the w.org CDN.

For testing purposes limited to meta.trac for now.

See #3526.

@ocean90 It seems like this unfortunately doesn't apply to the dynamic stylesheet URI's when included by

<script>jQuery.loadStyleSheet("https://s.w.org/style/trac/common/css/trac.css", "text/css");</script>

Causes both of these to be included:

I guess there's two options:

  1. Override the custom $.fn.loadStyleSheet to suffix the param (Which can be extracted from one of the existing stylesheets)
  2. Change the py:match to also match on <script>jQuery.loadStyleSheet( (and the script version too) and alter the URI in there?

#1 shouldn't be too hard to achieve in wp-trac.js, but I'm curious if #2 would be cleaner and longer-lasting?

#28 @dd32
2 months ago

All Tracs (including core.trac.wordpress.org) have now been migrated. We can start applying the fixes globally.

Override the custom $.fn.loadStyleSheet to suffix the param

I'm going to go ahead and do that short-term as I can test it out (I don't have a local Trac env), and it should fix the main thing people will notice (broken styled previews)

#29 @dd32
2 months ago

  • Priority changed from normal to high

Bumping priority to get a property change listed on the ticket for testing.

#30 @dd32
2 months ago

In 7083:

Trac: Remove a Mozilla hack which will no longer work as $.browser has been removed and Trac has updated the jQuery version it uses.

The bug appears to be closed as WorksForMe on the mozilla end.
See https://bugzilla.mozilla.org/show_bug.cgi?id=394782
See https://core.trac.wordpress.org/ticket/17051
See #3526.

#31 @dd32
2 months ago

In 7085:

Trac: Suffix cache buster keys to dynamically loaded JS/CSS files.

See #3526

#32 @dd32
2 months ago

In 7086:

Trac: Fix the 'Commits' section to work with jQuery 1.9.
As of 1.9 .after() cannot be used outside of the DOM, switch to using .append().

See #3526.

#33 @dd32
2 months ago

In 7087:

Trac: Update wp-trac.css with some more-specific selectors and overrides for Trac 1.2.2 CSS.

See #3526

#34 @dd32
2 months ago

In 7088:

Trac: Sync our copy of the trac htdocs with Trac-1.2.2

This brings in the required CSS & JS trac uses.
Source: https://svn.edgewall.org/repos/trac/tags/trac-1.2.2/trac/htdocs/

This change may cause some CSS & JS breakage where we've overridden the old trac CSS/JS with our own.

See #3526

#35 @dd32
2 months ago

In 7089:

Trac: Bump the scripts_version for new assets.

See #3526

#36 @dd32
2 months ago

In 7090:

Trac: Move 'Add Comment' to before 'Modify Ticket'.

This uses JS to move it, not ideal but we move a lot of the page around with JS already.

See #3526.

#37 @dd32
2 months ago

In 7091:

Trac: Show the property changes inline in comment previews.

See #3526.

#38 @dd32
2 months ago

In 7092:

Trac: Correct the colour of the logout link. This was previously an <a> but is now a <button>.

See #3526.

#39 @dd32
2 months ago

In 7093:

Trac: Append a version string to Trac's JavaScript/CSS files hosted on the w.org CDN.

This was previously enabled for meta.trac only as testing. It seems to have worked out well. Promoting to all Tracs.

Props ocean90.
See #3526.

#40 follow-ups: @dd32
2 months ago

Looks like I broke the TicketGraph plugin with r7088, Trac now has jQuery 1.9 which dropped the $.browser property.

The Ticket Graph plugin (We're running 1.0-WordPress) version we're using uses an out-of-date jQuery library.

The latest version appears to have a more recent version of the library, I'm not sure what changes we made to the library though.

https://github.com/trac-hacks/TracTicketGraph
https://meta.trac.wordpress.org/ticketgraph

#41 in reply to: ↑ 40 @dd32
2 months ago

Replying to dd32:

The Ticket Graph plugin (We're running 1.0-WordPress) version we're using uses an out-of-date jQuery library.

The latest version appears to have a more recent version of the library, I'm not sure what changes we made to the library though.

https://github.com/nacin/TracTicketGraph

  • Added Query by Ticket Type (defect/enhancement/task)
  • sqlite & mysql support
  • increased from 30days to 90days by default

Looks like https://github.com/trac-hacks/TracTicketGraph should probably easily merge into our version.

#42 @ocean90
2 months ago

In 7094:

Trac: Update wp-trac.css with some more-specific selectors and overrides for Trac 1.2.2 CSS.

See #3526.

#43 @ocean90
2 months ago

In 7105:

Trac: Update wp-trac.css with some more-specific selectors and overrides for Trac 1.2.2 CSS.

See #3526.

#44 @ocean90
2 months ago

In 7108:

Trac: Update wp-trac.css with some more-specific selectors and overrides for Trac 1.2.2 CSS.

See #3526.

#45 @ocean90
2 months ago

In 7110:

Trac: Make Trac ticket buttons always visible instead of only on hover.

See #3526.

#46 @ocean90
2 months ago

In 7111:

Slack/Trac: Improve detection of Trac email footer.

Some Trac installs like BuddyPress have an extra space after the separator which breaks parsing the mail.

See #3526.

This ticket was mentioned in Slack in #meta-tracdev by dd32. View the logs.


2 months ago

This ticket was mentioned in Slack in #meta by netweb. View the logs.


2 months ago

#49 in reply to: ↑ 40 ; follow-up: @Otto42
2 months ago

Replying to dd32:

Looks like I broke the TicketGraph plugin with r7088, Trac now has jQuery 1.9 which dropped the $.browser property.

Adding in jQuery-migrate should fix that issue in the short term.

#50 in reply to: ↑ 49 @dd32
2 months ago

Replying to Otto42:

Adding in jQuery-migrate should fix that issue in the short term.

Upgrading the plugin will also fix it, which should happen today. It seems like the newer version of the Trac plugin included all our modifications.

#51 @dd32
2 months ago

#3589 was marked as a duplicate.

#52 @dd32
8 weeks ago

The Ticket Graph plugin has been upgraded by Systems, looks to be working well. Might need to force-refresh your browser.

#53 in reply to: ↑ 13 @netweb
6 weeks ago

Replying to ocean90:

Replying to ocean90:

In 7064:

Slack/Trac: Add support for attachment notification mails.

See #3526.

Per @ocean90 in Slack #meta-trac:

That happens because https://meta.trac.wordpress.org/changeset/7064/sites/trunk/svn.wordpress.org/bin/slack-trac-hook.php doesn't work on BuddyPress (and bbPress?) Trac since the notifications are base64 encoded…

For reference, I added 3 patches and updated a BP ticket just now which resulted in 4 new ticket notifications in each of the in #buddypress-firehose and #buddypress Slack channels.

I'm not sure what is needed to be updated for bbPress and BudyPress Tracs (possibly plugins, themes, meta, i18n) to resolve this issue but it would be grand if someone with the access to the bb's Trac configs could take a look please.

#54 @netweb
5 weeks ago

Via Slack: https://wordpress.slack.com/archives/C02QB8GMM/p1526048941000668

@jjj wrote:

"Boone noticed today that the BuddyPress Trac isn’t showing up in Google’s search results anymore. Have we experienced that across other Trac installs?"

hlashbrooke wrote:

this query on google returns results" site:buddypress.trac.wordpress.org (edited)

so it is indexed, but buddypress trac returns non-trac things only, which is weird?
meta trac does the same thing for me, but core trac shows up in results like normal

#55 @boonebgorges
5 weeks ago

Thanks @netweb - to be clear, Google is still returning results, but far fewer than it should. site:buddypress.trac.wordpress.org activity favorite should get hundreds of hits, but for me it only gets four.

#56 follow-up: @ocean90
5 weeks ago

We had such an issue before, see #245.

nacin:
With the help of dd32 I tracked down where bots were getting blocked.

@dd32 and @nacin: Do you remember what the cause was and if it has been reintroduced during the upgrade?

#57 in reply to: ↑ 56 ; follow-up: @dd32
5 weeks ago

Replying to ocean90:

@dd32 Do you remember what the cause was and if it has been reintroduced during the upgrade?

It looks like it was something that Webmaster tools pulled up, I no longer have access to that though. Google Analytics console doesn't have anything (didn't expect it to).

$ curl --user-agent "Googlebot/2.1 (+http://www.google.com/bot.html)" -v https://core.trac.wordpress.org/

HTTP/2 403
...
<title>403 Forbidden</title>

Looks like bots are blocked from Trac entirely, which affects Googlebots ability to crawl it. I'll mention it to systems.

#58 in reply to: ↑ 57 @dd32
5 weeks ago

Replying to dd32:

Replying to ocean90:

@dd32 Do you remember what the cause was and if it has been reintroduced during the upgrade?

It looks like it was something that Webmaster tools pulled up, I no longer have access to that though. Google Analytics console doesn't have anything (didn't expect it to).

$ curl --user-agent "Googlebot/2.1 (+http://www.google.com/bot.html)" -v https://core.trac.wordpress.org/

HTTP/2 403
...
<title>403 Forbidden</title>

Looks like bots are blocked from Trac entirely, which affects Googlebots ability to crawl it. I'll mention it to systems.

Bot block has been lifted for some tracs, it'll take Google a few days to catch up..

#59 @iandunn
5 weeks ago

Possibly related (to the ticket in general, not the latest comments): #3594

#60 @dd32
12 days ago

In 7280:

Trac: Add some more specific stylings for the mobile view with the new Trac.

See #3526.
Fixes #3610/

Note: See TracTickets for help on using tickets.