MadeMyDay

So I call $page->URL in my templates and the navigation creation? Okay, sounds easy. But what about urls generated with TinyMCE for example? I could change the url module of TinyMCE of course. But is there perhaps a way to hook into the core url() function so I could just extend it with your function? Thanks for your help Ryan, much appreciated!

Hey Ryan, thanks for your answer. I think the biggest benefit of the alternate fields is to handle a website with one tree. That is always preferable if you have a 1:1 translation of most of the pages in your site where not all of the fields need to be translated. But of course it is always nicer to have "speaking" urls in each language (for SEO also as for users). Your suggestion with an extra field would be straight forward, but beside the language gateway template I would also have to hack in the URL generation process I guess. Is there a better way to accomplish that than by doing some If language == en then iterate over the path and use the alternate name field for URL creation? How would a slim solution look like? I think this would be a usual requirement for "real" multilanguage websites and a huge advantage over concurrent systems.

Hello everybody, I want to use one tree for different languages - as proposed in the API section - with a prepended /en/ oder /de/. That works fine. But is there a way to define an alternate "name" field for each language? Should work the same as with title and any other language_alternate field. Goal ist to have domain.com/en/products/productA in english and domain.com/de/produkte/produktA in german for example. How can that be accomplished? Thx in advance for suggestions! Marc

Quick question to Soma's approach: Is there (technically or performance-wise) a difference between defining the templates as templates and use $p->render and defining them as usual files using include(tplFile.php)?

Perhaps I misunderstood the whole concept, but: Is it correct that there is no (default) english source of the language files? So the package Ryan provided above is a starting point for translations that might change over time? Say I have a german translation for my site, I would take Nico's translations (thanks for that btw!) and add the missing phrases, but would not recognize if a whole language file is missing if I don't compare the package above by hand, correct? If so, wouldn't it be better to keep a default language package (english) in the core distribution and not only check the missing phrases of (exisiting) individual files but also keep track of added (new) translation files?

Glad it helped ;-) @Ryan: I guess it would be a good idea to mention that on the aquirements section. http://bugs.mysql.com/bug.php?id=32202

Which MySQL version do you use? There was a problem with 5.0.51 (afair) which had a sorting issue.

Something new on this? Is this already implememented? A client also wants to change the title attribute (although I try to teach him that this has no effects) :-/

Hi Ryan, thanks for your thoughts. Well, as said above: When you remove an original, the references are gone, too. No problem with that. I would use a "media"-node with several pages under it, so it is clear that if I delete an item from the database it is gone. Customers also can be teached to understand that. Yeah, this is what I tried to describe above. I think it would be sufficient to add an "id" column to the images/files (always have files in mind, why not treat them the same). And then just put the id of the referenced file in the "data" column. The outputFormatting has "only" to check if the data is a number (INT) and if so, just fetch the original/referenced data, could be a global function fetchOriginalFile() for example. If the original doesn't exist, the output does nothing, the inputField would render a message once (referenced file deleted [x] ). So I - from my noob point of view - think that extending the file/image table with an id column as well as extending the involved classes by a if (is_int(image['data']) image['data'] = fetchOriginal(image['data']); could work (pseudocode). But of course I don't know the internals of PW (yet). I think a page[id]-[fieldname]-[filename].jpg looks a bit like a workaround, which is harder to extend. With the id approach I think it could be also easier to extend the file fields with more fields like title, tags and so on. I am aware that PW usually encourages me to use pages for that, but especially the image upload function is so nice that I would rather use that

So here we go: http://siebennull.com/PWfileReference/ I hope it gets clearer ;-)

Hi Ryan, Ah, okay. Sorry for mixing this up. Okay, since in the end the images/files should be searchable (as well as the fields added to it) I think these columns could be generated when a new field configuration is saved. But this is later on the roadmap ;-) yes, this looks helpful. Also Atti's redirect module is a good starting point for module settings. I'll put something together ;-)

Thanks Ryan! Some questions regarding this module: Is it possible to define a database schema of an inputfield "on the fly"? Say we have a configuration option for additional fields and I add another field ("title" for example) for one particular field (e.g. "myImage"). Does PW create this database column on first call or how can this be done? (also answer to Atti): I think if a referenced image/file is deleted the reference should also be deleted (with a once showed note). Reasonable? Are there some docs showing how to start such a project? I am a bit lost 8) I think first I should duplicate the image inputfield (+ fieldtype, right?) and try to create references first. Given that (hopefully) I would have to "hack" into the code where the page object is created, so a $image->title will become possible. How is this done usually? Thanks in advance! Marc

Exactly. What do you think Atti? Reasonable, possible?

Hi Alan, I know the file manager. But this is another scope. What I want to achieve is a combination of uploadable files on a page and the selection of already uploaded files on other pages. Let's take the example page of Ryan (the one with the skyscrapers). Here every skyscraper has one or more images which could be shown on other pages (architects) by creating many to many relations, which works great. But think of other kind of pages like press releases where you want to show only specific images which are already uploaded somewhere. At the moment you can either upload them again for that specific page or you know on which pages on which position they are and include them by hand with a selector. What I want to achieve is that you have the possibility to select single images from other pages by referencing them without duplicates. So if for example a skyscraper image is changed (perhaps of copyright problems) all images referencing this image are also changed. With that the necessity of a media database is obsolete, because you can easily build it with pages. Or you don't build it and use all images/files site-wide as your media source.

Ryan, thank you for your thoughts. For the last 2 hours I tried to understand the structure of fieldtypes and inputfields and since I am not the PHP pro I am learning slowly ;-) So what I think would be a possible approach: A new module "inputFieldImageBrowsable" or something like that. This module extends the inputFieldImage module with addtional functionalities: adds a new column "imageID" or something to the standard field_image table adds a new button "browse site images" to the image field Configuration: parent: the pages where to look for images (like a "media" node) type: file extensions to look for more things later (search by, more fields for each image, only landscape/portrait etc.) button opens fancybox with grid/list view of the images (with url as "data", see below) found in [parent] possible to browse through pages via InputfieldPageListSelect selection of one or more images by clicking submit closes fancybox and shows the images The original extended fields (like description) get copied, but are overwritable images get new entry in table, but instead of url in field "data" only a reference to the id of the original image is stored (INT). For that approach also the page render function (?) needs to be extended and has to check the data (if INT use url of original image), so $image->url doesn't output the id but the url of the referenced image. Also the render input has to be extended for displaying the referenced images which then can be mixed with uploaded images. I think the same module could also handle ordinary files (also makes sense: Think of document management for manuals which are either added for a single page but can also be referenced on other pages). Why all that? Well, pretty simple: With that approach you could easily change images and files site-wide without changing every single page only by changing the original file. And I think the possibility of mixing uploaded and referenced files in one field would be an exclusive feature compared to other systems Sounds reasonable? OT: Edit on Chrome/Mac messes something up in this forum (cannot use "full editor" either, but luckily "save" works ;-) )

Hi Ryan, Exactly. But not as a select for the page name (or the images url), more a visual approach by listing the images in a grid for example. Pretty much as Atti's (I think) inputfieldImageFlickr-thing. Thought about reusing this module but not by pulling flickr images but all images on the site (perhaps categorized by pages). I will take a look in the Page reference fieldtype. yeah, of course. This is the way I did it this in MODX. But it would be handy not only to pull standard values (parent or special page) and also not only define by page name but more visual by clicking on an image. Like in TinyMCE. But the approach in TinyMCE is different I guess because the result is the path to image which is then hardcoded in the content area. I would prefere the page (+image number) reference. Thinking out loud: - Fieldtype like image (drag&drop + select image from local disk) plus a "browse images from system" button which opens a popup/layer like in TinyMCE. Perhaps not a good idea because the input result is different (images fieldtype store url + description I think, the browse option should store the reference to the original image with an optional possibility to overwrite the original description) - So better approach I think: Different fieldtype which stores an array of references which can then be accessed like an ordinary image field by $page->myImages->url for example. While typing this I still think a combination of the two fieldtypes would be nice but surely harder to implement Okay, I just looked in the database. The image fieldtype doesn't story a unique ID, right? So a reference to a single image (not the url) could become difficult, right?

Thanks for clarifying this, makes sense ;-)

Quick question: Is there a module/inputfield type for images like the one in TinyMCE where you set pages and get the images listed? This would be very handy for avoiding that clients upload images again and again. Thx in advance!

Hi Atti, thanks for your module! I am a bit confused about the usage, though... How am I supposed to access the backend? The module rewrites the URL so I can access my pages under the domain page, but the admin page can't be moved inside this domain page. But without that I cannot access it because the URL domain.com/processwire/ is catched by the module and tries to redirect to domain.com/domain.com/processwire which fails. Thx for help! edit: I changed line 40 into: if(strpos($httpHost, $subdomain) !== false && strpos($httpHost, 'admin') !== false) { which works for now. But I think this is not intended, so I would appreciate the "proper" solution ;-) Another edit: How is the homepage supposed to work? Now it is the root page, but with several domains it would be nice to have several homepages (under the domain page or the domain page itself). What do you think?

Since Yellowled also knows MODX very well (hi btw ) I just want to give my two cents to the topic with some MODX comparisons. In MODX you usually have snippets which do the logic an chunks which do the presentation. In PW you either define the logic yourself (often foreach over a set of pages) or have modules which do that for you. For the markup there seem to be several approaches. Soma showed two of them, echoing the markup right in the template and rendering external templates. While I don't like the "echo"-approach (it just looks ugly) the render() afaik can only render page templates. So I tried something different and to my surprise (well, not really) it works well. You just can organize yourself like in MODX. I even called my folder for mini templates "chunks". For example in my current project (my portfolio) I have a list of client work stored in a folder with an own template (for assigning the fields). This reference template has no own .php file, because they are not shown on a single page (it is a one pager). I have a overview list with some thumbs and then more details on every item later: <section id="references"> <article class="overview ref active"> <?php $refs = $pages->get("/referenzen/")->children; $count = 0; foreach($refs as $ref) include("./tpl/overview.inc"); ?> </article> <?php $count = 0; foreach($refs as $ref) include("./tpl/ref.inc"); ?> So basically I just loop over my references and "oldschool" include my chunk which looks like this: <? if($count != 0){ ?> <div class="screenOverview imgContainer ref<?= $count ?>"> <picture class="c" data-nr="<?= $count ?>" alt="Screenshot von <?= $ref->title ?>"> <!-- <source src="<?= $ref->image_c->width(384)->url ?>"> --> <source src="<?= $ref->image_c->width(384)->url ?>"> <!-- <source src="<?= $ref->image_c->width(550)->url ?>" media="(min-width: 1000px)"> --> <source src="<?= $ref->image_c->width(550)->url ?>" media="(min-width: 1000px)"> <!-- <source src="<?= $ref->image_c->width(650)->url ?>" media="(min-width: 1280px)"> --> <source src="<?= $ref->image_c->width(650)->url ?>" media="(min-width: 1280px)"> <!-- Fallback content for non-JS browsers. Same src as the initial source element. --> <noscript><img src="<?= $ref->image_c->width(550)->url ?>" alt="<?= $ref->title ?>"></noscript> </picture> </div> <? } $count++ ?> (using the picture polyfill in this case). So this means: you can just include any file and stay better organized. The variables are assigned and you even can reuse these "chunks". In the second loop I iterate again over the references and build something different (with description and such) with a different "chunk". Works pretty well and lets you keep well organized.

Ryan, thank you very much. Having alternatives is always good and the text log is exactly what I was looking for

Hello everybody, just digging deeper in PW and stumbling upon the question how to debug modules etc. There is an errorlog.txt generated and filled on exceptions (I think), but how can I debug variables and functions in modules? Is there an API for that? Like $error->log($foo, $bar) or something? I don't think that my way of var_dump($foo); break; is the way to go ;-) Thanks in advance, Marc

I have the Same "problem" with my host. Cant look right now but I think the solution was to look in your .htaccess for a commented line with the RewriteBase, just uncomment it so that it is like RewriteBase / Will look tomorrow at my installations.

Hi Pete, yes, I already took at the head.inc template and the (one level) navigation is straightforward. But if dealing with more levels it gets a bit more complicated. Of course it is doable, but I think a navigation as unordered list is used on nearly every website so a module for it seems appropriate. Hi Soma, well... I am impressed! This is exact the way how I would do it ;-) Perfect! Im am eagerly looking forward to use it. I am MODX user since 6 years, but disappointed by the current development (extJS, slow manager, you all know it) and this chaotic business model. PW really seems to be as flexible and the roadmap is a dream (matrix thingie, draft mode, versions, form generator etc.). I think I will start an extra thread with some questions, nice to see MODXers here which then know what I am talking about ;-) Greetings from Germany, Marc

Hey Soma, I am new to PW and just checking out the possibilities by reading hours in the forums before getting my hands dirty ;-) The navigation was on the schedule today and I like your module (also coming from MODX and looking for a wayfinder replacement). Your module seems to do more or less exactly what one needs for a navigation. But one (or two) suggestions: I would like to be able to define the output myself, because habits or requirements are different. Sometimes I need an additonal <span> somewhere or would like to use another field as title (or well, a title at all ;-) ) and so on. Since PW doesn't use any template or placeholder syntax I am not sure how to do so without hacking your module. Antoher example: the active class should be appended to the <li> element since this is the element which is active, not a child of it. I often need to style the <li> element and the containing <a> element as well. I your markup this is hard to accomplish, other way around it would be easy (you already mentioned an upcoming option for that). But as I said, requirements differ all the time and the most flexible solution would be to define the markup myself (or falling back to the standard output of course). Thank you for your solution(s), I will try PW on a "real" project soon.