netcarver

Ok, out of interest, what worker module is your Apache install using?

---

Ben,

sorry but a follow-up Q: is your apache2 executable compiled with multi-threaded support by any chance?

On linux I can get at this with

apache2ctl -V

but don't know how on Windows .

Tom,

try this (untested)...

<? $image = $profile->images->first();
$alt = ($image->description) ? $image->description : $image->name;
    echo "<img src='{$image->url}' height='{$image->height}' width='{$image->width}' alt='{$alt}' />";
?>

Hi Ben,

Welcome to the PW forum & thanks for posting this. I'm new to ProcessWire myself but want to ask if this problem shows up if you run ap with just a single thread?

Great topic! Thanks for posting Tom and good to see you in a forum again.

I used to use something similar to Ryan's tools.inc back in Textpattern but called it glue.php and had it live in the plugin cache directory.

+1 for this.

Ryan,

You might want to think about adding the target doctype to the constructor call now that textile can target HTML5. Not sure how you'd want to have the user indicate their preferred output type though. Presumably, if a site is targeting HTML5 then some kind of site-wide setting, or config option would do it.

$textile = new Textile('html5');

Currently this causes textile to output <abbr> instead of <acronym> and drops the invalid align attribute on images, instead inserting classes to allow CSS to do the alignment.

I committed some updates to PHP textile today. Added since post #28 above were...

• Support for HTML5 output.
  
• Support for symbols as backref link characters for note lists.
  
• Support for raw urlencoding of unicode characters in URLs.
  
• Simpler forms of "$" style links.
  
• More robust support for n-dash characters.
  

If I can, I'd like to add better support for Japanese-wikipedia style links (info here) and close a problem with line breaks in table cells; and that should get PHP Textile to version 2.4.

Great info and tests, thanks Netcarver! I'm thinking RTL support should come pretty easily for ProcessWire. One person had asked about Hebrew awhile back, but I didn't know enough at the time to provide a good answer. Now I do. It sounds like you are a VIM user too?

Glad that helps & yes, I use gvim most of the time.

Ok, I got some follow up from a helpful RTL language user from the Textpattern forum & things are different to what I initially memory dumped.

I started off by having Google translate the greeting "Hello"[en] into [ar] and got "مرحبا" as the result. My friend confirmed that "م" is the first letter (looks slightly different in the phrase as it joins to the next char) and "ا" is the last character. I then put together a small test page that puts out both the English and Arabic with various combinations of the dir and lang attributes to see what effects these have on the renderings and looked at the output in Firefox and Chromium.

A summary of the results...

• Both browsers render the test output identically.
  
• The dir="xyz" attribute only seems to control the alignment of the output, not the direction in which the string is rendered: the browsers themselves seem to be figuring out the correct way to render a sequence of characters.
  
• The lang="xyz" does not change the alignment, nor the directionality of the rendered output but does make a difference to the font selected to do the rendering.
  
• It seems that the editor you use to view the source file does make a difference to what you see in the php. On my linux box gedit renders the Arabic as RTL within the quotation marks, whilst Vim renders it LTR.
  
• A hexdump of the php shows that the Arabic string is indeed stored in the file with the first character following the opening quote mark and the last character before the close quote. So, whilst vim shows it literally, it looks backward (to an Arabic reader.)
  

Hope that helps.

I'm chasing this up with a RTL language user from the Textpattern CMS forums as my recall of this aspect is poor and may be incorrect.

Are my old eyes deceiving me or is there a spurious return at line 47 in wire/modules/SessionLoginThrottle.module -- or am I totally misunderstanding how this method works ?

public function sessionAllowLogin($event) {
return;
$name = $event->arguments[0];
...

Hi Ryan,

thanks for the reply.

I think for the sites that adopt flags, they do it because it's pretty, looks international, and can catch the eye quicker. Also, maybe there isn't a technical 1-to-1 relationship among many, but the communication is still there (though I'm sure there are exceptions).

For something that involves a very large number of languages, then I agree flags lead to inaccurate generalizations. But when I go to a site in another language, I see the US or British flag a lot quicker than I see the word "English", so I tend to have a slight usability preference for the flags (as a user). Even if they aren't perfect, they are a familiar landmark in a sea of unfamiliar language where it's easier to spot landmarks than words. For me the worst cases are when sites use language names in a dropdown selection, and the label on the dropown is not one that I can read to even know what it's for.

Yeah, they certainly draw the eye so I do get this as a positional anchor in unfamiliar text.

I guess I'm pretty biased as I lived in Malaysia for a number of years and there are four commonly used languages there (English, Malay, Chinese and Tamil) but one flag. Yes, you could chose the US or UK flag for English, the Malaysian for Malay, the Chinese for Chinese and the Indian for Tamil but for sites aimed at a domestic audience that would force many viewers to identify with outside nations when the majority of visitors would be Malaysian.

Despite my personal preferences, the use of a consistent markup of language codes as CSS classes gave site designers using the MLP Pack the flexibility to implement a number of alternate selection schemes. In fact, many sites that were made with the MLP Pack simply used CSS to add flag icons to their rendering of the site's language choices. If you keep all your flag icons in a common directory and name them according to the language code it's trivial to do.

I'm a little afraid of this just from an SEO standpoint. This clearly violates Google's webmaster guidelines (delivering different textual content at the same URL based on client-side factors), but maybe they have an exception for a case like this? (at least that would make sense)

Yes, and it also stops your browser caching the incorrect language output for a given URL. The use-case for the above was for when visitors would omit a language code from the URL, if the language code was present they'd always get the same text. Looking back on it, it does violate Google's guidelines for missing codes.

It sounds like RTL support has more to do with the markup than anything else? Are you aware of any factors on the data storage side?

Not aware of any. If I remember correctly, you still treat all your strings internally as left-to-right but the browser just starts over on the right-hand side of the containing block and works over leftward when rendering the strings in rtl blocks.

[Edited to add: I may be remember this wrong as a non RTL language user myself. I'll see if I can chase up some RTL language users from the Textpattern CMS forum and check it out.]

So this php...

$out = "abcdefg";
echo '<div dir="ltr">' . $out . '</div>';
echo '<div dir="rtl">' . $out . '</div>';

...would render text like...

abcdefg

gfedcba

I do remember there being some very strange looking rtl output for strings with punctuation, though I can't give any concrete examples here.

Edited to add: The above example is incorrect. Following further testing (see below) the output is as follows...

abcdefg

and the direction of the string itself seems to depend on the code-points used in the string with the browser automatically rendering them as required.

Hello formmailer,

As exchange rates usually vary quite slowly, how about just caching the last value you successfully get each time and fall back to that if a read fails. You could also have your module email you if reading fails a number of times.

Edited to add: This might not be acceptable for some applications that may require a certain amount of 'freshness' to the data or to data from sites where the TOS forbid caching.

We've kind of skipped over the issue of language names in PW, and are letting people use whatever names they want for their languages (whether iso/codes, names, or something else). Though the <html> lang attribute, and PHP setlocale() codes are set with the translation files. But the intention here was just to broaden the utility of the language capabilities. For instance...

Ah, that opens up quite a lot of flexibility that my scheme didn't have without resorting to adding non-standard entries to the array I posted. I can see how that could work well for languages tailored to specific roles or domain knowledge, mainly in the admin interface I would have thought.

BTW, I did things this way in the MLP Pack as there was a lot of utility in combining the codes used for the HTML lang & dir attributes and the localized script names in public facing applications, not just in the admin interface. In public facing multilingual sites I wanted new visitors to be able to quickly locate and switch to their language of choice (if available) which is probably still best done with the local script name rather than something more arbitrary. There are other solutions to presenting such a selection rather than using some string. For instance, some sites adopt the use of flag icons to indicate language choice. I personally think this is a bad idea. Flags intrinsically represent nations, not languages, and there is seldom a one-to-one relationship between them (at least not now) and for residents of the many multilingual nations (like India, Canada, Malaysia, Indonesia, Singapore etc) using flags as language indicators just doesn't make sense. Linux installers take the local script name route too, presenting a big menu of language choices using the names for the language in the native script. That kind of covers the first base: what to call (label) your language choice.

The other base is the use of standard language codes -- which it sounds like you have covered as data in the translation files. Using the standard language codes also allows you to implement automatic language selection. For example, most browsers will submit an Accept-Language request header using 2 character codes. Server side you can pull these codes out of the headers and use them to auto-select the correct (or best) language for your visitor's browser and fall back on a site-wide default as a last resort. Even then you'll probably still need a language selector of some kind that makes sense to the visitor as often the visitor will not have configured (or cannot configure) their Accept-Language headers to correctly identify their preferred language.

Apologies if most of that covers ground you have nailed in PW, just dumping it in case.

I've not done anything with regard to right-to-left languages, and don't have a good understanding of what is necessary to support them. The question has come up before. What is your experience in supporting these languages? I'm curious what steps we would need to take (if any?) to properly support them.

The RTL support in Firefox seems pretty good to me but I can't really speak for other browsers. RTL layout is triggered by marking up an applicable place in your HTML with a dir="rtl" attribute (or "ltr" or "automatic"). You can apply this markup to multiple page elements as required and even nest them. So if you had an English document which quoted some RTL language like Urdu (ur) then you could do something like <body lang="en" dir="ltr"> and then mark all the block quotes with lang="ur" dir="rtl".

I didn't take RTL support any further than this and several RTL language users in the Textpattern community seemed happy enough with it.

I know I'm coming to this late and that Ryan has put a lot of effort into the multilingual features in pw. I'm not sure if this will be of any use or interest for presenting a language-select feature in pw but here's a gist of most ISO 693-1 Languages in their own script and includes direction rendering information for those that render right-to-left. Encoded in utf-8 so should render correctly if you have the necessary code-points installed in a font on your system and it also includes a few regional variations (eg. for Taiwanese vs mainland Chinese.)

I just pulled this out of my, now rather outdated, Multi-Lingual Publishing (MLP) Pack for Textpattern CMS.

Actually, this could be possible right now as well - symlinking your db files into repo on one end, ...

Sure, but I'm pretty dumb and would probably forget to add the multiple files that MySQL creates behind the scenes for each new table I may end up adding to my database. SQLite would be easier in this respect.

As I'd probably create and modify templates more frequently than I would add tables, I probably wouldn't have the same issues remembering to add the template files to the repo.

Not at present, but definitely interested in doing that for the future. It's just a matter of time/resources and putting it towards the stuff that matters most in the short term. Longer term it would be really nice to have something like this, especially as PW gets used more and more as a framework.

Ok, look forward to that. At least I'd have some confidence that my tinkering wasn't breaking things -- or an early warning if it were.

I would version control your /site/templates/ and /site/modules/, but not your /site/assets/ as they are tied to DB entries. Though if you combine it with a DB export for each commit, then that would solve it. But this is something we'll have built-in version control for, further down the road.

Sounds good. I guess eventually having SQLite support would give another option for this too as you could just put the single DB file into your set of tracked files.

Hey netcarver, regarding versioning presentation elements - since ProcessWire deals with raw data and makes no assumption what you'll do with them code-wise, this part is totally up to you - if you wish, you can store HTML in the database (as I did on multiple occasions, where it made sense to store data with basic HTML around it), or you can store 'pure' text, checkboxes, textareas in db and have full code in your template files - so this is totally up to you.

And regarding database, I'll leave this to someone more knowledgable.

Hi adamkiss,

Ok, so could I just version control all the files in the /site directory? I guess I could, that would kind of make sense.

Not sure if this is the best place to post this but here goes anyway.

As a followup to my initial installation of pw, I just did another and sat looking at the final set of messages from the installer for a while thinking something looked a bit, err, disjoint with a couple of the messages.

In the list were these two, not next to each other in the list, but in this order...

1. Now that the installer is complete, it is highly recommended that you make ./site/config.php non-writable! This is important for security.
   
2. There are additional configuration options available in this file that you may want to review: ./site/config.php
   

Now, as a total newbie to pw, if I do the first I won't be able to do any editing that might be needed in the second part of the message without undoing what I just made read-only, then applying my edits and making it read-only again.

Ok, I guess that in most cases, the second stage will be a review with no editing needed. But that might not be the case -- and might even change in future versions (another guess.)

So perhaps these two could be rationalized into one, something like...

"Now that the installer is complete, please review and, if needed, update the contents of ./site/config.php before marking it read-only.

NB: For security it is highly recommended that you make ./site/config.php non-writable!"

Would this simplify things for newbies?

Hi Alan,

Haven't we met before somewhere? Anyway, you are almost there with your code. Welcome to the world of regular expressions. Now, to go from...

// _What are hedgehogs?__Hedgehogs are

...to...

// What are hedgehogs?_Hedgehogs are

You need to do a couple of extra steps if you want the PHP workout and can't find anything else. If you store what you want to echo in $out then do this (I'm showing it in two steps but you can combine if you want)...

$out = strtr( $out, array( '  ' => ' ' ) ); // All double space runs to single space runs
$out = trim( $out ); // No leading or trailing spaces.
echo $out;

You should get your target result.

@Ryan,

Out of curiosity, is there a set of unit tests/fixtures for pw? Something that folks could take and use to ensure stuff they were working wasn't breaking anything? I didn't spot anything during a brief look at the pw directory structure.

Hi Folks,

Very informative topic, answers several questions I had about the DB choices in pw.

I too would like to see pw adopt a more flexible attitude to backend DB engine and even sub-engine as I have found InnoDB to be a more reliable storage engine than MyISAM in MySQL. I see that InnoDB, too, has recently gained fulltext index support so I hope whatever DB extensions make it into pw also include a MySQL+InnoDB option.

Further, and keeping with the Textpattern theme that kicked off the topic, there seems to have been a recent trend amoung some Textpattern users to move Textpattern's presentation elements (pages/forms/styles) out of the DB and onto the server filesystem (at least while sites are under development) in order to allow them to be placed under version control. I do this myself for some sites I develop in Textpattern and there is a useful plugin that facilitates this.

Is the same possible in pw?

Hi Adam,

Sorry, I totally blanked on your initial reply to apeisa so I missed your link to Neon. I'll check it out.

Ok, took a look and you're right. Neon looks more flexible regarding leading tabs / spaces but lacks a lot of YAMLs more complex features -- which may well be fine for this application -- and it gives you good error reports. However, I think my general point may still hold true if people who aren't familiar with the leading whitespace requirements end up editing those files, and especially if the parser errors are not exposed fully to the user.

Also we might think about using YAML, since that is pretty nice to look at and write, but not sure.

Hi,

A thought on YAML: whilst it is a very nice format (I use it for test fixtures) please be aware that it is whitespace intolerant as it uses leading indentation/spacing to delimit structures a bit like Python or HAML do. You need to configure your editor carefully to preserve existing leading space if you are to work with YAML files. If it is just you going to be editing these then that might not be a problem, but once users of your system start editing them you could be in for some extra support work if they don't configure their editors well.

I've used a single file library called spyc before and found it very effective at meeting my YAML processing needs.

Hello all,

First time user of pw here and I like what I'm seeing; a lot. Ryan and all the contributors have done a great job on this project so thank you to one and all.

Coming from a background writing plugins for Textpattern CMS I thought I'd start off looking at the modules system. Being able to git clone a module right into a test installation is very nice but I quickly found myself having to scroll through lots (and lots, and lots) of entries to locate the first module I cloned before I could hit the install button.

Soooo, I took a look a the code and decided to simply have the message about newly available modules link to its entry in the list. Makes installation much less scroll-prone.

You can check it out for yourselves at https://github.com/n...ver/ProcessWire and I've submitted this to Ryan as a pull request.

Hope this is useful to someone here.