CiviCRM Community Forums (archive)

README Install:

Should add a mention of the minimum php version (cli 5.3?)

Probably a good idea.

I wanted to use my own fork of civix, is there an easy way with composer?

You can do this:

1. On github, make a fork of the "civix" project. Note the URL.
2. git clone git@github.com:MYUSER/civix.git
3. cd civix
4. php /path/to/composer.phar install

step 2) php composer.phar create-project civicrm/civix complains about missing parameters.yml (that is for step3) Should the order be changed?
3) app/config/parameters.yml not sure what the purpose of it, as it's supposed to generate extensions working for several civi installs, why does it need so many info, and stuff like the api keys.
Does it does the manipulation over rest?
civicrm_api3_path is this the external/bin/rest.php or the civicrm/ajax/rest ?

Why does it need to manipulate the dev instance in the first place?

add one line
update civicrm_contact set api_key='aaaa' where id=1;

Yeah, I recently added the ability for civix to connect to a dev instance of CiviCRM. The parameters.yml is supposed to record the details, but I didn't retest that process well enough. I'll try to clean that up in the next day or so.

The main use-cases would be things like: (a) flush the civicrm menu (aka URL routing) when the developer calls "generate:page" and (b) extract the definition of a custom-data group and save it as part of an extension. At the moment, most of that functionality is theoretical rather than real.

I think I'll need to make this optional -- ie if you run "generate:page" and have an active connection, then it will autoflush; if there is no connection, then remind the developer to do the flush.

where is twig used? and there is a bit of web, but all the examples are cli, am I missing something

Twig isn't really used. The civix commands are implemented using Symfony conventions (as a sort of stress-test/training scenario for me), and Symfony bundles in Twig by default. One could use twig for the source-code template files (src/CRM/CivixBundle/Resources/views/Code), but the .php templates are working so far, and I don't view twig (or any "templating" system) as the best solution for code-generation -- I'd rather do something with a PHP AST.

The "web" directory also isn't used, but Symfony's tooling expects it by default, and I haven't spent any time to figure how to remove it properly. (IIRC, removing it will produce errors when composer runs the "installAssets" step.)

Side node: I will get used to the namespace separator on php, but find the \ quite weird looking

Ditto

Missing features

I will need to create/read config data. Something like variable_get variable_set on drupal.

Wondering if the api settings will be able to handle that instead of having to

CRM_Core_BAO_Setting::getItem('com.example.foo', 'my_setting')
* In the civicrm.settings.php
  global $civicrm_setting;
  $civicrm_setting['com.example.foo']['my_setting'] = 'bar';

Regarding the general point about variable_get(), there are probably a couple dozen things like variable_get, drupal_set_message, drupal_add_js, etc, where we need to document the Civi equivalents -- something like this but more easily edited -- and updated for civix:

http://arms.dl.locker10.com/devel-doc/cheatsheet.html

Do we have a good medium for maintaining a large table of code snippets? We could use Confluence, but it feels hard to keep code snippets organized -- I'd almost rather do something with Drupal+CCK. Do we just bite the bullet and use the wiki? Or would it be better to just write a "tutorial" that touches on the important utilities?

Regarding the CiviCRM "Settings" specifically... the getItem() statement is uglier than variable_get(), but you'll survive it, and the civicrm.settings.php stuff is the same as Drupal. I don't know where the API-ification stands. We'd have to ask Eileen.

So I've generated a first module

civix generate:module eu.tttp.public_autocomplete
and got a "Malformed package name"

It seems that it doesn't like underscore. Is this a constraint of civicrm extensions in general or a limitation of civix?


civix generate:module eu.tttp.publicautocomplete


And in generated the needed files.

I started modifying the info.xml and ran again civix generate:module. It silently replaced the existing files. Shouldn't it display a warning and "the extension exists already, would you like to replace it?"


The group has write access to the files
-rw-rw-r-- 1 xavier xavier  661 2012-07-13 15:07 info.xml
-rw-rw-r-- 1 xavier xavier 2237 2012-07-13 15:07 publicautocomplete.civix.php
-rw-rw-r-- 1 xavier xavier 1253 2012-07-13 15:07 publicautocomplete.php
I would like it to be like the default (g is read only), unless there is a specific reason. Is this an option or can it be switched to the debian/ubuntu default (-rw-r--r--) ?

Can you use .extra.tpl for those two forms ?
http://civicrm.org/blogs/dave-greenberg/now-its-easier-add-custom-behaviors-templates

In buildForm you also have access to $form->getTemplate(), so you might be able to insert something into the smarty object too.

1. You can append any js in the .extra.tpl file

2. In 4.2 the .extra.tpl works for event/contrib/profile specific templates

3. the permissions that files get created in general are determined by your user account umask. In general its not good practice to fudge around with them (IMO)

4. _ is a special character within Civi for classnames. we use it to demarcate directory boundaries

lobo

Responses to a few points from the thread (in no particular order):

1. To create a zip file, run "civix build:zip"

2. Regarding file overwrites, other commands (like generate:page and generate:upgrader) are more cautious, but I didn't anticipate someone calling "generate:module" twice. We can fix that.

3. In publicautocomplete_civicrm_config(), you wrote a line to update the include path:

  set_include_path(get_include_path() . PATH_SEPARATOR . $path);

This shouldn't be necessary -- the auto-generated helper, _publicautocomplete_civix_civicrm_config(), should register the extension in both PHP and Smarty include paths.

4. I don't know if CiviCRM allows underscores in the fully qualified extension names -- I haven't heard of anyone trying nonalphanumeric characters. If those are legit, then we could loosen up civix's validation by modifying:

https://github.com/totten/civix/blob/master/src/CRM/CivixBundle/Command/InitCommand.php#L34

5. Regarding extra.tpl, we could merge in this patch which allows multiple modules to add page content:

http://forum.civicrm.org/index.php/topic,19278.msg90156.html#msg90156

There was a design question about how many different regions to include in core templates, but we could take a pretty coarse-grained approach (extra.tpl is pretty coarse) -- perhaps a region for the HTML HEAD (<style>, <script>) and regions the page's header, body, and footer.

Re: using the .extra.tpl

My point was that they can be only one and only one bla.extra.tpl, so if the extension creates a bla.extra.tpl, then the site custom template  folder can't define it too, right?

So if we start using .extra in an extension, then you deny the other extensions/custom template folder the right to include one.

Unless I misunderstood the way .extra works.

Ok for underscore, my bad.

For the postprocess, will try and report, didn't know this feature.