hwmaier

Peter, Thanks for testing and confirming the fix. I will add your confirmation to the Github issue list notes and hopefully this fix is adopted at some stage by Ryan into the main release. Henrik

Done. Refer to https://github.com/ryancramerdesign/ProcessWire/issues/929

I thought that $config->styles and $config->scripts are the official containers for gathering and collecting scripts and CSS for frontend output. On https://processwire.com/api/variables/config/ it says " Feel free to use it for the same purpose in your own sites.". Maybe I mistunderstood something here and if there are issues with this approach or it is not recomended this probably should be spelled out in the documentation.

It would be beneficial if the FilenameArray class would have a count() method. Suggested implementation: class FilenameArray implements IteratorAggregate, Countable { ... /** * Returns the number of items in this FilenameArray. * * Fulfills Countable interface. * * @return int */ public function count() { return count($this->data); } Rationale: A count method can be used to check if any scripts or stylesheets are configured as shown in the following example: <?if (count($config->scripts)):?> <script type="text/javascript" src="<?=AllInOneMinify::JS($config->scripts?>"></script> <?endif?> The current implementation of FilenameArray does not implement the Countable interface and count() will return a 1 regardless of the number of elements in the FilenameArray.

The CSS compression bug I described in my earlier post has been fixed in AIOM version 3.2.

The seems to be a bug with the CSS compression. #nav :hover{} becomes when compressed: #nav:hover{} The blank should not be removed as it is a separator between a parent and a child element and removing it changes the cascade! The the first rule identifies a child element of a #nav element which is hovered over like the anchor link in this HTML snippet: <div id="nav"><a href="/">I am a hovering child element</a><div> and the latter identifies just the #nav element itself which is hovered over like: <div id="nav"> I am a hovering parent element. My children don't matter. <div> As a consequence this bug breaks CSS based menus.

If {team->body} has hanna code formatter enabled, then it will not work as Hanna Code 1.9 does not support recursive Hanna code processing. Refer to my earlier post. Remove the {$team->body} statement from your code snippet and check the result whether it then outputs all 9 members. Once you see that working, try using the patched version of Hanna Code I submitted on Github.

I usually use this approach for Hanna Code. A few initial lines in pure PHP code to init vars and prepare data enclosed in a <?php ... ?> tag and then follows the HTML "view" using PHP's alternative syntax to fill in variables and control structures like loops. <?php $images = wire()->page->images->findTag($tag); ?> <?foreach ($images as $image):?> <p><img src="<?=$image->url?>" alt="<?=$image->description?>"></p> <?if ($image->description):?> <small><?=$image->description?></small> <?endif?> <?endforeach?> This approach allows separation of logic from presentation but still encapsulates both within a Hanna Code component.

Did anyone figure out whether it is possible to add existing pages to the PageTable when using a parent for item storage?

I had a similar experience and found that this happens when HannaCode renders a field which again contains some HannaCode. I submitted a patch to support recursive HannaCode to git. You could try out if it fixes your issue by replacing the TextformatterHannaCode.module file with the one in this fork: https://github.com/hwmaier/ProcessHannaCode/blob/master/TextformatterHannaCode.module

In September 2014 the new wirePopulateStringTags() function was added to the core. Looking at this it appears to be a great foundation to introduce some sort of placeholder functionality into ProcessWire. Is there a TextFormatter module planned to utilize this new feature or maybe even some form of integration into the Hanna code module so that placeholders can be passed as Hanna code attribute values?

A pull request has been issued, let's see whether Ryan adopts the change. This would likely also fix the issue reported here: https://github.com/ryancramerdesign/ProcessHannaCode/issues/8

Recursive Hanna Code Hanna Code currently (version 1.9) does not support recursive Hanna tags, for example one Hanna Code tag is rendereing a partial which again contains another Hanna Code tag. As I needed that requirement I made changes to support recursion to my private repository. Is that something useful to the wider community? If yes I could issue a pull request.

Hi all, I am just curious about a weird style sheet insertion issue with ProcessRedirects and AIOM I came across. Maybe somebody can shed some light on this. I upgraded to version 1.0.1 published by renobird. I am also using AIOM and found that when using AIOM in development mode (only then) a style sheet /site/modules/ProcessRedirects/ProcessRedirects.css?v=101 is added to the $config->styles array which then fails to load as absolute paths are not [yet] supported by AIOM. I also saw that ProcessRedirects version 1.0.1 has renamed the style sheet to ProcessRedirects2.css and once I remove ProcessRedirects.css from the /site/modules/ProcessRedirects directory, the style sheet is not added to the array any more. Is this a known thing? And is this issue the reason why the style sheet was renamed from ProcessRedirects.css to ProcessRedirects2.css?

Yes, it seems a bit quirky, but legal YAML syntax. And in PHP its also legal to mix numeric and associative indices in arrays. I found it useful for long lists of about 30+ elements where most elements are "anonymous" and are just iterated, but a few required direct access, so needed to have a known key (like a tag). It would be a pain having to assign indices to all elements and would spoil the beauty and ease of YAML. Either way, you decide with version to choose, I only want to share my experience with the various versions and the subtle differences.

@owzim That would be good. I worked with both versoins of Symfony\Yaml. The 2.0.x and the newer 2.1.x branches. I found the 2.0.x (currently at 2.0.15) branch more flexible with the syntax, as it allows things like mixing list and associative array elements, for example: - Entry 1 tag2: Entry 2 - Entry3 which is kind of nice as it allows you to create arrays where some elements have a named array index and other just anonymous numeric indexes. Versions from 2.1.x onwards throw an exception 'You cannot define a sequence item when in a mapping' for this use case. Refer to http://gitelephant.cypresslab.net/symfony-2/commit/a1b73887f7de2a2549a7d2606b7803edc35af61d

Thanks for the contribution. I used YAML in past PHP projects outside of ProcessWire a lot and found it very useful. Great to see now support in PorcessWire for it. I also used initially SpyC but found its parsing not as robust and compliant and subsequently switched to Symfony's Yaml component which I found a better parser. For example Spyc does not support correctly anchors with newline folds > (item: > &anchor). Migrating from SpyC to Symfony\Yaml is easy, just replace Spyc::YAMLLoad($sourceFile); with Symfony\Component\Yaml\Yaml::parse($sourceFile);. Should you decide to migrate to the Symfony compnent, use the 2.0.* branch of Symfony\Yaml which still does support mixing list and associative array elements which the 2.1.* branch does not allow any more despite it being correct YAML syntax. If you use composer "require": { "symfony/yaml": "2.0.*" }, will pull in the correct Yaml library.

Hi all, I found a small glitch in HannCode version 1.9. This only affects Hanna Code tag names which contain a . (dot) character and at the same time contain attributes. For example: [[admin.email]] or [[admin_email recaptcha="true"]] both work as expected and get processed and replaced. But this [[admin.email recaptcha="true"]] does not. In file TextformatterHannaCode.module change line 242 from if(preg_match('!^([-_a-z0-9]+)([\s,]|$)!i', $expression, $matches)) { to: if(preg_match('!^([\.-_a-z0-9]+)([\s,]|$)!i', $expression, $matches)) { solves the issue. What is the best way to submit bugfixes/patches? Should I fork this on github and post a pull request?