The PEAR_Exception class is not found. It need to be added to the composer file somehow. It's extended through Console_CommandLine_Exception

PEAR_Exception GitHub repo is https://github.com/pear/PEAR_Exception/

Will issue PR if I can figure out how to get this in.

I've set the title front layout variable in my entry, but neither {{ title }} nor {{ this.title }} seems to work in the default.twig layout. Any ideas?

Currently you should be able to compile your site to a specific directory using phr up [src] [dst]. I have two problems with this.

1. For some reason ../is appended to the directory. So when I try phr up .phrozn/ test/ it compiles to my current directory. To have to place the files in test I must use phr up .phrozn/ test/test/.

2. Compiling to a different directory than the current one should be far more common than compiling from another directory than where .phrozn resides, since that is most likely your project's root. Hence I suggest the [src]and [dst] parameters switch order.

Following the websites "Installation" page, I was getting an exception when trying to run phr relating to a file not being found. I figured out that when I installed PEAR (sudo apt-get install php-pear) it would then work. Aren't the PEAR dependencies supposed to be included in the phrozn package? If PEAR is a dependency, it should be included on the installation page.

This PR is related to discussion: https://github.com/farazdagi/phrozn/issues/5

In practice this PR allows an user to use Phrozn in different ways:

Usual

phr init
phr up
phr single index.twig
phr clobber

In this way as usual the .phrozn folder was craeted at init and all works normally.

Not standard folders

phr init src
mkdir htdocs
phr up src htdocs

The project src contains the Phrozn project (no .phrozn folder) and all the generated files are in htdocs folder.

Project foldering

- src
  - plugins
  - entries
    - index.twig
    - ...
- htdocs
  - index.html
  - ...

Clear the project folders

phr clobber src

This destroy the project folder for not standard structure.

Plugins autoloading

To support this feature the plugin autoloader is loaded in order to work in the right folder.

Hi mates,

just another PR. Actually the compilation process when someone put a permalink strategy the .html is appended by default. This trend could be a problem if I need to create particular pages for eg: permalink: /installer that is a script file.

I think that if place a permalink Phrozn has to use my permalink and not append .html, of course if I create a permalink as /create/this/path/ the result is /create/this/path/index.html

What do you think about this?

Bye

From chatlog:

srsly, is there no way of installing phrozn using pear without being root? I've tried installing pear to my home dir (using debian) with no problems, and installing phrozn into that dir, but phr gives me a lot of wierd errors are the lib paths hard coded?

Using IDE like netbeans having the default dir as ./phrozn causes hidden directory in the file explorer.

Good to have the folder setting as a config option.

The first 3 commits are required just to get "phr init" + "phr up" to work on windows. I tried to make the changes as unintrusive as possible.

You should really decide whether you want to always use "/" as the directory separator, or always use the DIRECTORY_SEPARATOR constant. Either is good, but mixing them up is what causes problems on windows. For start, I just normalized the separators where needed to make "phr up" work.

In the fourth commit I started fixing tests so they pass on windows. Again, it's linux-specific stuff that fails, see commit messages.

I tested on Travis so you should be OK to merge, but just look over everything in case I messed something up, since I'm not that familiar with the codebase.

Cheers, Ivan

This is a rahash of #83, but with working tests. I'm somewhat new to GitHub pull requests: if there is a better way to correct someone else's PR, let me know and I'll resubmit it that way.

The changes in test files are mostly superficial: things like spacing, indentation, and capitalization in CSS hex colors brought on by updating the libraries to the latest versions using composer.

The changes in the textile output files are weird: the original files had incorrect element nesting and shouldn't have passed. Presumably there was a bug in the original Textile parser.

Solving issue #59.

Many failing unit tests on dev branch. Do not blame me for that :-) We'll fix them on separate pull request. Please check my changes, maybe you'll have some comments.

1. From this page: http://phrozn.info/en/documentation/articles/getting-started/ The link to the sample site is broken: http://sample.phrozn.info/
2. The footer, presumably on any page, is linking to the broken link: Wizardcat, http://wizardcat.com/eng
3. The main page http://phrozn.info/en/ links to code coverage, which is broken: http://test.phrozn.info/
4. Deprecated link: There's a link somewhere in the site that still links to the old phrozn-site repository, which has a readme saying that it is deprecated! But the link on the site still links to it.

I really like Phrozn, but wanted to make it easier to use Google Prettify within Markdown. It's possible to configure the Markdown parser to include the required 'prettyprint' class on the <pre> tag, but there was no way to do that within Phrozn.

This pull request corrects that. It's a fairly simple change only to the Markdown processor to look for likely configuration settings in both the front matter and the sitewide config.yml. While this opens up all the configurable parts of Markdown Extra, my original goal of making code blocks play with Google Prettify is achieved by adding this to config.yml

markdown:
    code_class_prefix: "prettyprint lang-"
    code_attr_on_pre: true

Using this I can format code in Markdown with fenced code blocks which also hint at the syntax to be used

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ js
 {
    "foo": "sample JSON",
    "bar": "http://www.example.com"
 }
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Markdown will render that with <pre class="prettyprint lang-js"><code>...</code></pre> and the Google Prettify script will play nicely with it.

I think it will be better to split this repo into two separate: phozn and phozn-skeleton-app (for example).

Pros:

• simplify phrozn version maintenance during projects lifetime
• allow to create projects via composer (composer create-project pawka/phrozn-skeleton-app)
• allow for custom installation steps via composer scripts
• move tests for phrozn from app repo.

Cons:

• Breaks BC. Maybe for future releases?

Hello,

If I run

{
    "custom_field_redirect_fb": {
        "LONG_MD5_FIELD_ID": {
            "exists": {
                "step": "LONG_MD5_PAGE_ID",
                "page": "LONG_MD5_PAGE_ID"
            },
            "not_exists": {
                "step": "LONG_MD5_PAGE_ID",
                "page": "LONG_MD5_PAGE_ID"
            }
        }
    }
}

Through PHP-MarkDown I get

<p><code>{
    "custom_field_redirect_fb": {
        "LONG_MD5_FIELD_ID": {
            "exists": {
                "step": "LONG_MD5_PAGE_ID",
                "page": "LONG_MD5_PAGE_ID"
            },
            "not_exists": {
                "step": "LONG_MD5_PAGE_ID",
                "page": "LONG_MD5_PAGE_ID"
            }
        }
    }
}</code></p>

Yet when I run it through Phrozn it generates

<p><code>{
"custom_field_redirect_fb": {
"LONG_MD5_FIELD_ID": {
    "exists": {
        "step": "LONG_MD5_PAGE_ID",
        "page": "LONG_MD5_PAGE_ID"
    },
    "not_exists": {
        "step": "LONG_MD5_PAGE_ID",
        "page": "LONG_MD5_PAGE_ID"
    }
}
}
}</code></p>

For example, initialize a new site, and then view the about page:

GET http://example.org/about/scripts/bootstrap-dropdown.js 404 (Not Found)
GET http://example.org/about/styles/default.css 404 (Not Found) 
...

It would appear /layouts/default.twig needs to be changed to use absolute references instead of relative for both the styles and scripts sections.