'dynfields.js' is missing

[Tian Bai]

The Dynamic Fields functionality didn't work at all. I found that a 404 was returned when requesting '/trac/chrome/dynfields/dynfields.js'. 'dynfields.js' couldn't be found in either '0.12' or '0.11' branch (I'm using 0.12'). I'd guess 'dynfields.js' is missing for some reason.

Having searched around, I only managed to find 1 relevant chat log: ​http://pacopablo.com/irclogs/2010/12/17/#08:17:29.656301, where someone is sharing the same pain.

[Rob Guttman]

Thanks for submitting a ticket - it helps me know that things may be broken that need to be fixed. dynfields.js comes from the dynfields.html template file. That's just how Trac's templating works. As for why you're getting a 404, some things to check:

• Did you install the plugin using the setup.py as described here? That will make sure the static resources such as .html and .js are included. If you're having a problem with the 0.12 version, you can also try the 0.11 version which should also work under 0.12 but without multi-language support.
• Check that all of the template and other files are readable by all - or at least your web browser's user account. Here's one example of where the dynfields.html file lives and its permissions:

  root@dev4:/usr/local/lib/python2.6/dist-packages/TracDynamicFields-1.2.0-py2.6.egg/dynfields/templates# ls -al
  total 16
  drwxr-sr-x 2 root staff 4096 2010-12-15 14:16 .
  drwxr-sr-x 4 root staff 4096 2010-12-15 14:16 ..
  -rw-r--r-- 1 root staff 3012 2010-12-15 14:16 dynfields.html
  -rw-r--r-- 1 root staff 1325 2010-12-15 14:16 prefs_panel.html
  

• Also make sure that all aspects of the plugin are enabled in trac.ini or TracAdmin and that JavaScript is enabled in your web browser.

Let me know if these tips work or not. If not, then please share some more details about your environment such as Trac version, dynfields plugin version (latest is 1.2), and other plugins you have enabled (because sometimes plugins conflict with one another).

[Tian Bai]

I was using TracDynamicFields-2.2.0dev-py2.6.egg generated from 0.12, which turned out to be the problem. I switched to TracDynamicFields-1.2.0-py2.6.egg from 0.11, then it worked. Not sure if this is relevant, but I'm using Nginx as the web server.

I'm new to Trac. I followed the instruction to just copy the egg file to the /path/trac/plugins. Why / how it became a folder under /usr/local/lib/python2.6/dist-packages/ according to your example above? Please educate me.

If there is other information that you think may be helpful, I'm glad to provide. Thanks.

[Rob Guttman]

Replying to tianbai:

I was using TracDynamicFields-2.2.0dev-py2.6.egg generated from 0.12, which turned out to be the problem. I switched to TracDynamicFields-1.2.0-py2.6.egg from 0.11, then it worked.

Glad that it worked. Did you delete the 0.12 egg file/directory yet? Best not to have both installed at the same time.

I don't know why the 0.12 version did not work. I plan to merge these two branches soon so hopefully that will itself fix the 0.12 branch problem.

Not sure if this is relevant, but I'm using Nginx as the web server.

Good to know. I have never tested under nginx - not sure if that would have an impact here, especially if other plugins are working fine for you.

I'm new to Trac. I followed the instruction to just copy the egg file to the /path/trac/plugins. Why / how it became a folder under '/usr/local/lib/python2.6/dist-packages/' according to your example above? Please educate me.

Ah, yes, sorry - there are two general ways to install Trac plugins. The way I suggested (i.e., generating an egg file), is a good approach especially if you have multiple Trac instances running on the same host (and without virtualenv if you know what that is). The other way is to do a python setup.py install which will install the plugin usually as a directory that has the same name as the egg file but in python's standard site-packages or dist-packages directory. Either approach should work fine.

If there is other information that you think may be helpful, I'm glad to provide. Thanks.

I appreciate that. Some questions:

• Did you install Babel before installing the 0.12 version? It could be that the python portion of the plugin crashed at just the wrong place to cause the 404 but otherwise seem to be installed and properly enabled. Just guessing here - I would need to try that myself to see if that's possible.

• Curious: what features of dynfields had you install it? Are there features that it lacks that you want?

[Rob Guttman]

Closing as fixed/working on 0.11 - although still need to investigate the 0.12 branch issue.

[Tian Bai]

Replying to robguttman:

Replying to tianbai:

I was using TracDynamicFields-2.2.0dev-py2.6.egg generated from 0.12, which turned out to be the problem. I switched to TracDynamicFields-1.2.0-py2.6.egg from 0.11, then it worked.

Glad that it worked. Did you delete the 0.12 egg file/directory yet? Best not to have both installed at the same time.

Yes, I did. Thanks for the hint.

I don't know why the 0.12 version did not work. I plan to merge these two branches soon so hopefully that will itself fix the 0.12 branch problem.

Not sure if this is relevant, but I'm using Nginx as the web server.

Good to know. I have never tested under nginx - not sure if that would have an impact here, especially if other plugins are working fine for you.

I'm new to Trac. I followed the instruction to just copy the egg file to the /path/trac/plugins. Why / how it became a folder under '/usr/local/lib/python2.6/dist-packages/' according to your example above? Please educate me.

Ah, yes, sorry - there are two general ways to install Trac plugins. The way I suggested (i.e., generating an egg file), is a good approach especially if you have multiple Trac instances running on the same host (and without virtualenv if you know what that is). The other way is to do a python setup.py install which will install the plugin usually as a directory that has the same name as the egg file but in python's standard site-packages or dist-packages directory. Either approach should work fine.

If there is other information that you think may be helpful, I'm glad to provide. Thanks.

I appreciate that. Some questions:

• Did you install Babel before installing the 0.12 version? It could be that the python portion of the plugin crashed at just the wrong place to cause the 404 but otherwise seem to be installed and properly enabled. Just guessing here - I would need to try that myself to see if that's possible.

Someone else setup Trac and everything else, so I'm not sure. However, I did see babel.js requested (and successfully returned) when I inspected the webpage and found the 404 error, so I'd guess it's installed.

• Curious: what features of dynfields had you install it? Are there features that it lacks that you want?

My immediate need was the "hide/show" rule, with which 'milestone' / 'version' fields hide when the 'type' is "task". I really appreciate your work and would like to help make it even better. I do see some features missing, and more generally I'd prefer a more intuitive / integrated mechanism to define different kinds of rules, instead of splitting them into 4 kinds like they are now. I'll certainly think more about this and open feature request tickets.

[Steffen Hoffmann]

Just a quick note: The 0.12 branch is known to be broken, just not mentioned on the wiki page. Please, see the latest commit messages for that branch, especially the last changeset ([9690]). There I clearly stated, that I had issues, when testing, but no time so far to already fix it. Maybe I should have renamed it to trunk to clearer declare it's development branch nature.

Sorry for that, but as Rob already stated, we'll be merging that branch back for several reasons and resolve that issue in the way to a 0.11/0.12 compatibility version. I'd appreciate, if you'd check it out again after the merge and initial positive test reports from developers. Thank you for testing, report and patience.