Context URL

Your result when running it through code sniffer (also attached): http://ventral.org/pareview/httpgitdrupalorgsandboxgianfrasoft1387780git

You will need to setup a branch called 7.x-1.x instead of using the master branch.
A README.txt should be included with your module.

It appears you are working in the "master" branch in git. You should really be working in a version specific branch. The most direct documentation on this is Moving from a master branch to a version branch. For additional resources please see the documentation about release naming conventions and creating a branch in git.
Review of the master branch:

• README.txt is missing, see the guidelines for in-project documentation.
• Drupal Code Sniffer has found some code style issues (please check the Drupal coding standards). See attachment.

This automated report was generated with PAReview.sh, your friendly project application review script. You can also use the online version to check your project. Get a review bonus and we will come back to your application sooner.

Manual review :

1) contexturl.info

Clean your info file by removing :

version = "7.x-1.x-dev"
core = "7.x" (appear twice)
project = "contexturl"

I'm sorry, don't RTBC your own issues

Hi,-
please
1. remove duplicate
core = "7.x"
from contexturl.info
2. please write README.txt

branches have nothing to do with folders or their structure, please read the documentation about how to use git on drupal.org

to access the files, i have to go 3 level after branch .. is that permitted? (http://drupalcode.org/sandbox/gianfrasoft/1387780.git/tree/refs/heads/7....)

Hi gianfrasoft,

As #15 suggested, you need to move the files up to the same directly your .git is in, so the repository is a list of the files in your project, not a container directory.

Closing due to lack of activity. Feel free to reopen if you are still working on this application.

Please, release this as full project: I'm using subpathauto and context modules, but no context can be set with urls like node/*/sub-page.

I think this module can resolve this issue (can't it ?)

Thank you very much

PS: I've also evaluated this sandbox project: http://drupal.org/node/1475274 but seems that there is no more activities there...

Ok, I've tried to test your module, here's the results:

1. Iast commit doesn't work due to some folder issues (/plugins), so I've used the 4e1f397 commit snapshot.
2. I'm not sure about the use of:
   $current_url = $_SERVER['HTTP_HOST'].request_uri();
   in your execute() function, because it check all the url (ok, this is by design) but how do you manage it when you deploy your site from development to stage to production? You have to change the url in every ambient? For example:
   • www.yoursite.com/en/professionals/map
   • dev.yoursite.com/en/professionals/map
   • stage.yoursite.com/en/professionals/map.

   I think this module should limit the url checking only for the last part (using for example $current_url = request_path();) and leave to Domain Context module the management of complete urls.

3. Your execute function works only if only one path is written in the context condition textarea: if you write more than one path (one per line) the matching can't works and the condition is not triggered. So the module have to manage better multivalues in $options['pageurl']

However this is a very useful module: thank you for working on it!

Hope this help

Good work!

I have tested the latest copy of the module and it's not currently working, however I did supply a patch (as I actually need this module) to get it back on track as well as extended an offer to help mentor the developer to get the module ready to release.

Thank you Deciphered!

FYI in the meantime I'm using Context Request Path that works like a charm.

Can we hope for an integration between these two modules? For example the feature to check ALL the full url or only the final part could be an option to choose from.

Thank you very much

MXT,

My specific need is only achievable with the Context URL module, so I can't really comment on integration with the two, and it's really up to the two developers to discuss that prospect, but in general I'm all for collaboration.

Project applications are tasks. Only reviewers should assign project application issues to themselves. The project application title should reflect the module/theme name.

You need to set the status to "needs review" if you want to get a review, see http://drupal.org/node/532400

I've left one last set of notes on coding standards, just regarding whitespace in a few of the files.

There's a few other minor issues via Coder, but I think this is definitely in a releasable state.

I would recommend some reading of Git workflow as there seemed to be quite a bit of confusion, tagging a sandbox release and such, but good work otherwise. Happy enough to mark it as RTBC.

@MXT,

Looking back at your comments on #21, I have to completely disagree, the reason I wanted this module was that I don't want the complexity of the Domain module but I want a way to switch certain reactions based on the domain of the URL for the purposes of environment switching.

For example, with this module plus my recently released Contextual variables module I can set a reaction on www.mysite.com* that will disable the Environment indicator from showing up and I didn't need to resort to the complexity of the Domain Access module to do it, simply a Context condition and reaction.

If anything, I would vote that this module should only deal with the domain part of the URL as for me the path can be managed via the existing reactions, but I see no reason to reduce that functionality when it doesn't hurt anyone.

@Deciphered,

in my #23 I've already proposed to add an interface option that could resolve the impasse: a simple radio-button like this for example:

[] check ALL the full url (domain included).
[] check only the final part of the URL (request_path).

Could this be the solution to meet all needs and make this module really complete?

Hi Gianfranco.

It appears you are working in the "master" branch in git. You should really be working in a version specific branch. The most direct documentation on this is Moving from a master branch to a version branch. For additional resources please see the documentation about release naming conventions and creating a branch in git.
Your branch should be named "7.x-1.x" (so you need to delete the branch "7.x-1.0" as well).

Additionally you've already created a tag named "7.x-1.0" which is basically an indicator for the first stable release (which is not ready yet).

Leaving this behind the module looks very clean and very (!) usefull.

It wasn't clear to me form the project description what your module does - especially since Context already supports path matching. I think you could use a few examples on how it works instead of just referring to fnmatch.

What is on the first line of your README? I see it in my browser as \feff.

These kinds of comments are useless - either put something helpful in there or just delete them :)

/**
  * condition_values function
  */
function condition_values() {
  return array(1 => t('True'));
}

There's a typo in your plugin, "forumula" should be "formula".

Instead of $_SERVER['HTTP_HOST'] I think you can use the global $base_url variable. The boolean logic in your execute() function is a little messy, you could definitely clean that up, but it seems like it would work. You should also remove the master and 7.x-1.0 branch, and just work out of your 7.x-1.x branch only. When you are ready for a point release (7.x-1.0) - that's a tag that you make from the 7.x-1.x branch.

These are mostly minor issues though, except for maybe the git branches, but I don't see any critical problems.

This may be a duplicate of Context Domain, although context domain doesn't seem to have a release? Not sure how to handle that.

Thanks for the extra info, you already have RTBC from me :)

Thanks for your contribution, gianfrasoft!

I updated your account to let you promote this to a full project and also create new projects as either a sandbox or a "full" project.

Here are some recommended readings to help with excellent maintainership:

• Dries' post on Responsible maintainers
• Best practices for creating and maintaining projects
• Maintaining a drupal.org project with Git
• Commit messages - providing history and credit
• Release naming conventions.
• Helping maintainers in the issue queues

You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and get involved!

Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.

Thanks to the dedicated reviewer(s) as well.