petsagouris

And while on the CSS Framework discussion it is quite easy to use a preprocessor to get what you need and customize the framework exactly as you need it. Twitter Boostrap uses LESS and Foundation uses SASS. This lets you take what you need from them.

@soma thanks for merging the ssl fix. Here is something of interest: Github repository API for the archive link

@pwired, please state the model of the camera so that people can search for the it's specifications and abilities to help out efficiently.

@Henning: The Google documentation about creating sitemaps says:

A Sitemap file is independent of the language of the content. To make sure that each language version can be crawled and indexed, use unique URLs. These URLs can all be included in your Sitemap files.

So basically each domain has one sitemap.xml. You put all of the pages in it.

Unless I am missing something this module does not work for individual languages in fields that have language support. I tried doing it on my own but I have little knowledge of Processwire inner workings to make this happen. I've even tried stepping and evaluating expressions with XDebug to no avail.

Can anyone give me pointers on the following two things:

1.  Getting the $languages array inside the PageEditFieldPermissionConfig function
2.  Checking that the current field in the field traversal is actually a Language supporting one.

Furthermore I'd like to ask Ryan, if there is a reason that the PageEditFieldPermissionConfig function is placed in its own file?

I am asking because there seems to be very little need to do so, since the PageEditFieldPermission::getModuleConfigInputfields() is just requiring the file and returning the function result immediately.

edit: By achieving this, there is just one thing missing to open up the way for the translator roles and that is making the inputs viewable but disabled.

Please look at this topic.

Stop the drama you ...sensationalists!

@horst relax, you are gonna have a heart attack. Sharpening matters to you, I get it.

There are two possible explanation why Image manipulation libraries have basic sharpening.

a) 90% of the people will never notice the difference between soft, medium, strong sharpening. Many of them may even not be satisfied with the sharpening that is done by the library because they might have chosen the wrong one.

b) The web isn't about image quality that much, 72dpi doesn't let it matter.

Recognizing that this is an area of your expertise I'd recommend you help the guys on that library out so PHP in general gets an advantage (and you get attributed for it too).

Image manipulation is something that has been dealt with many times, please, please use an existing library for this.

Imagine is the most downloaded and starred lib for this on packagist so they must be doing something correctly.

Ryan, considering the PHP versions after 5.3.7 have the Blowfish problem solved shouldn't the check as follows?

public function supportsBlowfish() {
    return version_compare(PHP_VERSION, '5.3.7') >= 0 && defined("CRYPT_BLOWFISH") && CRYPT_BLOWFISH;
}

@mindplay.dk Could you please share what type/amount of work you've put into the effort to namespace Processwire's source?

(Maybe this belongs in another topic all together?)

@petsagouris: A tiny typo in your preg_replace(), change $input to $str.

Thanks, done.

It seems that TinyMCE used to have an option to do what Peter wants but it is nowhere to be found in the tinymce source (TinyMCE configuration: remove_linebreaks)

The TextFormatter should look something like this (not tested apart from the regexp):

<?php
/**
 * TextFormatter to put new line character after a specified set of end tags.
 */
class TextformatterNewlineAfterTags extends Textformatter {

  public static function getModuleInfo() {
    return array(
      'title' => 'Line characters after specific HTML tags',
      'version' => 100,
      'summary' => "Adds line characters after the <br> and </p> end tags. ",
    );
  }
  public function format(&$str) {
    $str = preg_replace('/(?:<\\/p>)|(?:<br\\s*\\/?>)/', '$0\\n', $str);
  }
}
 

Why would you want to read the article in the HTML source?

The solution to the deep namespace problems is just a matter of using namespace aliasing.

Code standards are great and a great tool to check on them is PHP_CodeSniffer. In an IDE such as PHPStorm (Ryan I am so sorry) you could just put the formating rules in place and just tell it to reformat the whole thing.

But this is all details compared to converting the source to PSR-0.

Provided that the LanguageParser inside Processwire can parse a file and identify the translatable strings I believe that it would be fairly easy to get all the files parsed and have the resulting files dumped in a folder in any format. It would be best to have that invocable (http request or commandline) since it may or may not be a heavy operation run only sporadically in development.

I'd like to add that in Transifex there are "resources" (the master language files) that may be set up to be fetched periodically from a public repository making the upadting of the strings inside those resources a non issue for the developers.

$field->collapsed|notes are going to be treated the same as the $field->label in the above example. All the magic attributes are known before hand by the Inputfield so there is no problem to actually pass an array and let the Inputfield object do the work of assigning the configuration to the object.

From the first post it isn't clear that the intent is not to remove existing behavior. The object creation is not going away in fact it is going to be used at the Inputfield level (at a deeper level in the inheritance tree) by using the data inputted from the field configuration array.

The way I have understood the current situation is that making a field is basically "configuring" a field. Since there is nothing dynamic about inputing configuration, that is exactly what I am proposing to make easier.

I have been digging in the Processwire source to find out how everything works for making some contributions.

I noticed that module configuration is similarly to this (Taken from the ModulesManager module by Soma):

static public function getModuleConfigInputfields(array $data) {
  $data = array_merge(self::$defaults, $data);

  $fields = new InputfieldWrapper();
  $modules = wire("modules");
    
  $field = $modules->get("InputfieldText");
  $field->attr('name', 'apikey');
  $field->attr('size', 10);
  $field->attr('value', $data['apikey']);
  $field->label = "modules.processwire.com APIkey";
  $fields->append($field);

  $field = $modules->get("InputfieldText");
  $field->attr('name', 'remoteurl');
  $field->attr('size', 0);
  $field->attr('value', $data['remoteurl']);
  $field->label = "URL to webservice";
  $fields->append($field);

  $field = $modules->get("InputfieldInteger");
  $field->attr('name', 'limit');
  $field->attr('value', $data['limit']);
  $field->label = "Limit";
  $fields->append($field);

  $field = $modules->get("InputfieldInteger");
  $field->attr('name', 'max_redirects');
  $field->attr('value', $data['max_redirects']);
  $field->label = "Max Redirects for file_get_contents stream context (in case)";
  $fields->append($field);

  return $fields;
}

Would it be cleaner if Processwire allowed for a way to pass an array to setup the fields and maybe even pass an array of arrays of fields to generate an InputfieldWrapper (for instance)?

something like:

static public function getModuleConfigInputfields(array $data) {
  $data = array_merge(self::$defaults, $data);

  $fields = new InputfieldWrapper();
  $modules = wire("modules");
   
  $fields->append(array(
    'module' => 'InputfieldText',
    'attributes' => array( 'name' => 'apikey', 'size' => 10, 'value' => $data['apikey'] ),
    'label' => _('modules.processwire.com APIkey'),
    ));

  $fields->append(array(
    'module' => 'InputfieldText',
    'attributes' => array( 'name' => 'remoteurl', 'size' => 0, 'value' => $data['remoteurl'] ),
    'label' => _('URL to webservice'),
    ));

  $fields->append(array(
    'module' => 'InputfieldInteger',
    'attributes' => array( 'name' => 'limit', 'value' => $data['limit'] ),
    'label' => _('Limit'),
    ));

  $fields->append(array(
    'module' => 'InputfieldInteger',
    'attributes' => array( 'name' => 'max_redirects', 'value' => $data['max_redirects'] ),
    'label' => _('Max Redirects for file_get_contents stream context (in case)'),
    ));
   
  return $fields;
}

Or even:

static public function getModuleConfigInputfields(array $data) {
  
  $data = array_merge(self::$defaults, $data);

  return new InputfieldWrapper(
    array(
      array(
        'module' => 'InputfieldText',
        'attributes' => array( 'name' => 'apikey', 'size' => 10, 'value' => $data['apikey'] ),
        'label' => _('modules.processwire.com APIkey'),
        ),
      array(
        'module' => 'InputfieldText',
        'attributes' => array( 'name' => 'remoteurl', 'size' => 0, 'value' => $data['remoteurl'] ),
        'label' => _('URL to webservice'),
      ),
      array(
        'module' => 'InputfieldInteger',
        'attributes' => array( 'name' => 'limit', 'value' => $data['limit'] ),
        'label' => _('Limit'),
        ),
      array(
        'module' => 'InputfieldInteger',
        'attributes' => array( 'name' => 'max_redirects', 'value' => $data['max_redirects'] ),
        'label' => _('Max Redirects for file_get_contents stream context (in case)'),
        )
      ));
}

Such a attitude towards form and input declaration can open the door to having forms stored in a structured static data format and just have them fed into to the appropriate container object.

If the 'array(' parts are too much on the eyes remember that PHP 5.4 has short array syntax using [ and ].

What are you missing again? Paths prefixes? you mean like /de/... /en/... ?

Those are set on the homepage name.

AHAH! Thats it!! At the most logical of places. Thanks for the tip Soma!

Sorry, have no more ideas. It's up to the pro's here.

Not a problem. Thanks for your help and persistence so far

Disabled the admin theme still no path prefix to the other language page. http://i.imgur.com/2FjYvBW.png

Replaced the 'wire' folder from the dev branch but still the same. I have even tried typing the path again hoping that it will get added but nothing has changed.

I also clapped my hands twice that didn't work too

Ah, good good thanks both of you for pointing that out. Is there a way to update my current installation to the latest dev branch ?

I have downloaded a fresh Processwire from the homepage and I am not seeing the screenshots as in Ryans screengrabs

What am I missing ?