Leaderboard
Popular Content
Showing content with the highest reputation on 10/28/2013 in all areas
-
In the end was an angularjs problem, two steps to solve it First: adding that piece of code to my .js angular.module('myApp') .config(function($httpProvider){ $httpProvider.defaults.useXDomain=true; delete $httpProvider.defaults.headers .common['X-Requested-With']; }); Second: adding what interrobang says to .htaccess # ------------------------------------------------------------------------------# | Cross-domain AJAX requests |# ------------------------------------------------------------------------------ # Enable cross-origin AJAX requests.# http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity# http://enable-cors.org/ <IfModule mod_headers.c>Header set Access-Control-Allow-Origin "*"</IfModule> Thanks to everybody.2 points
-
Just wanted to chime in and mention what I've done. I've been working on a new version of this module to support language page names. (mainly speaking only if LanguageSupportPageNames is installed) - support Multilanguage - support for correct view Actions from admin - correct urls within admin - modified locaUrl() to work correctly, coming from LanguageSupportNames module I hope you guys don't mind. I forked the project and comited current version. As you can see there's not much left from the original, but the basic concept is the same. This work was supported and sponsored partly by http://dreikon.de/ with whom I've been doing some PW support work lately. Since it's already some time ago since I made it (meanwhile tons of other work in my head) I just tested again locally with and without LanguageSupportPageNames installed and corrected a little issue. I'd very appreciate if you guys help test this version. And any help or suggestions are welcome. It may not the best code ever written, especially since it's kinda complex I'd be very happy if more eyes take a look. Ideally it would replace the current multisite module and be backward compatible. Thanks You can grab the module here: https://github.com/somatonic/Multisite2 points
-
Just wanted to share what I recently used to create forms in modules and in frontend using the API and Inputfield modules PW provides and uses on its own. I think many newcomers or also advanced user aren't aware what is already possible in templates with some simple and flexible code. Learning this can greatly help in any aspect when you develop with PW. It's not as easy and powerful as FormBuilder but a great example of what can be archieved within PW. Really? Tell me more The output markup generated with something like echo $form->render(); will be a like the one you get with FormBuilder or admin forms in backend. It's what PW is made of. Now since 2.2.5~ somewhere, the "required" option is possible for all fields (previous not) and that makes it easier a lot for validation and also it renders inline errors already nicely (due to Ryan FormBuilder yah!). For example the Password inputfield already provides two field to confirm the password and will validate it. De- and encryption method also exists. Or you can also use columns width setting for a field, which was added not so long ago. Some fields like Asm MultiSelect would require to also include their css and js to work but haven't tried. Also file uploads isn't there, but maybe at some point there will be more options. It would be still possible to code your own uploader when the form is submitted. Validation? If you understand a little more how PW works with forms and inputfields you can simply add you own validation, do hooks and lots of magic with very easy code to read and maintain. You can also use the processInput($input->post) method of a form that PW uses itself to validate a form. So getting to see if there was any errors is simply checking for $form->getErrors();. Also the $form->processInput($input->post) will prevent CSRF attacks and the form will append a hidden field automaticly. It's also worth noting that processInput() will work also with an array (key=>value) of data it doesn't have to be the one from $input->post. Styling? It works well if you take your own CSS or just pick the inputfields.css from the templates-admin folder as a start. Also the CSS file from the wire/modules/InputfieldRadios module can be helpful to add. And that's it. It's not very hard to get it display nicely. Here an code example of a simple form. <?php $out = ''; // create a new form field (also field wrapper) $form = $modules->get("InputfieldForm"); $form->action = "./"; $form->method = "post"; $form->attr("id+name",'subscribe-form'); // create a text input $field = $modules->get("InputfieldText"); $field->label = "Name"; $field->attr('id+name','name'); $field->required = 1; $form->append($field); // append the field to the form // create email field $field = $modules->get("InputfieldEmail"); $field->label = "E-Mail"; $field->attr('id+name','email'); $field->required = 1; $form->append($field); // append the field // you get the idea $field = $modules->get("InputfieldPassword"); $field->label = "Passwort"; $field->attr("id+name","pass"); $field->required = 1; $form->append($field); // oh a submit button! $submit = $modules->get("InputfieldSubmit"); $submit->attr("value","Subscribe"); $submit->attr("id+name","submit"); $form->append($submit); // form was submitted so we process the form if($input->post->submit) { // user submitted the form, process it and check for errors $form->processInput($input->post); // here is a good point for extra/custom validation and manipulate fields $email = $form->get("email"); if($email && (strpos($email->value,'@hotmail') !== FALSE)){ // attach an error to the field // and it will get displayed along the field $email->error("Sorry we don't accept hotmail addresses for now."); } if($form->getErrors()) { // the form is processed and populated // but contains errors $out .= $form->render(); } else { // do with the form what you like, create and save it as page // or send emails. to get the values you can use // $email = $form->get("email")->value; // $name = $form->get("name")->value; // $pass = $form->get("pass")->value; // // to sanitize input // $name = $sanitizer->text($input->post->name); // $email = $sanitizer->email($form->get("email")->value); $out .= "<p>Thanks! Your submission was successful."; } } else { // render out form without processing $out .= $form->render(); } include("./head.inc"); echo $out; include("./foot.inc"); Here the code snippet as gist github: https://gist.github.com/4027908 Maybe there's something I'm not aware of yet, so if there something to still care about just let me know. Maybe some example of hooks could be appended here too. Thanks Edit March 2017: This code still works in PW2.8 and PW3.1 point
-
I created a Modul which extends Language Translator (Core) Modul, with a select-field to choose translatable files not translated yet. But it doesn't work perfectly, because the language to be translated isn't set by default. Even if I use the Standard Language Translator, no translated files will be listed. Even then, if I have set translation files for all my languages. If I go to setup -> language, choose a language and start to edit a translation file, the language-to-translate will be set in the system. Now I can go to the Language Translator and it looks like I had expected: Just to be clear I am not talking about the user language. I think it would be useful either to have a Language Selector in the Module Language Translator to select the language before the files are (not) displayed, or to set a default language-to-translate, which will be displayed in the Head of Language Translator to be clear which language is in processing. I will have a deeper look to find a solution. 1 hour later: looks like it would work now. I initialized the modul with the users language by default, if nothing else is set (GET or SESSION) I made an update on github. Maybe its a better idea to make the Language-Translator a Child Page of the specific Language Page. ... or to go sleeping Good Night ... 17.10.13 Updated the Module today with a Language Switcher and a clear headline which let you know in which language you are. Working fine on my System now. Looks like: @experts: please check Get the Module here: https://github.com/kixe/ProcessLanguageTranslatorPlus or here: http://modules.processwire.com/modules/process-language-translator/1 point
-
Textformatter for Google Maps https://github.com/teppokoivula/TextformatterGoogleMaps This module looks for Google Maps URLs (such as https://maps.google.fi/maps?safe=off&ie=UTF-8&q=disneyland,+paris) within paragraph (<p></p>) HTML tags and automatically converts them to embedded maps. Configurable options include embed type ("static" or "iframe"), API key, responsive embedding and Google Maps for Business settings. Other than that, it's pretty basic stuff. Original regexp for grabbing maps links was posted by Ryan (I believe) here on the forums, but I couldn't find that post anymore. I've altered it to better suit the needs of this module, added some configurable features (part of which, such as makeResponsive() method, are again based on Ryan's TextformatterVideoEmbed module) and so on. Hope someone finds it useful. (By the way: if you're going to use Google Maps for Business settings, please read the notes there carefully. Google doesn't exactly recommend storing your private key the way module settings are stored..)1 point
-
I found myself searching for an smooth workflow to collaboratively work on a process wire project and had the challenge of including the mysql data into version control to keep it in sync with the rest of process wire. Here is a solution with git hooks, that Ben Kubertis came up with: http://ben.kulbertis...-and-git-hooks/ Step 1: When commiting you want to fetch the latest changes of the database. Edit the "pre-commit.sample" hook located in /YourRepoDirectory/.git/hooks/ #!/bin/sh mysqldump -u [db_user] -p[db_password] --skip-extended-insert [db_name] > /PathToYourRepo/database.sql cd /PathToYourRepo/ git add database.sql Enter your mysql login details and git repository paths and then save and rename it to "pre-commit" That way each time you commit, any changes of the db will be downloaded and kept under version control Please note: If you only have modified the database and didn't touch any other files, you will have to manually pull the database updates, since git commit needs "changed files" to successfully commit. Step 2: When you checkout or merge branches, then you always want to fire up the belonging database again. Create another two hooks named "post-merge" and "post-checkout" with the following content: mysql -u [db_user] -p[db_password] [db_name] < /PathToYourRepo/database.sql NOTE: !!! Please test this first on a dummy project, in order to not mess your database up !!! When working with MAMP you probably have to add the path to mysql and mysqldump as well; Simply put /Applications/MAMP/Library/bin/ in front of it1 point
-
Hi all, we lauched this big website for a festival last week, and pout a lot of work and love into this. Check out: boomfestival.org Hope you like it! and it has been received very well so far.. ( 60 000 visits in less then 1 week) It uses processwire as CMS , and I must say awesome decision to replace Wordpress we used the last editions, processwire is highly superior to wordpress as CMS . I even managed to import a lot of content from Wordpress with the Processwire bootstrap API and JSON and the help of this forum Content is loaded all with Ajax , and still backbutton does work and everything can be deeplinked . Ryan ProCache module has helped very much with Site speed and our high traffic server load If I find the time I might do a case study here...as this ajax approach moight be interesting for other developers1 point
-
Hi, I have a page with multiple languages (Language Plugins installed). When I first used the TinyMCE I actually though that setting a link would open the "Link to Page" page structure based on the language that I am just using the Editor with. But unfortunately it's always the language I picked in my profile. That means I would not be able to set a link to a page in a different language without switching my user language every time. Are there any solutions to show the "Link To Page" Field for all languages that a currently being used? So that the Editor would be able to set a link to to a page in language 1 or 2 or 3 and so on? Thank you. - Melrors1 point
-
Hi guys, i finally finished my personal website. PW and jQuery as always and Bootstrap as css framework. English version coming soon... http://complementaryart.com1 point
-
Hello, I've recently updated a showcase website for (private) antique collection. http://agcat.net/ Module I used: - Procache - Batcher This website is expected to be written in Japanese/English, but English texts are not available yet. Developing this website, I thought Processwire would be a fantastic solution to organise and show cultural heritage such as museum collections!1 point
-
I implemented this about a month ag oas I need it too but Ryan hasn't yet taken it into core. Busy times I guess.1 point
-
Ah. That explains a lot. Famous (as I am (with my family at least)) hater of the bad joke that is the UI and UX of Facebook (regardless of any other failings it may have), I too would avoid a Like button that Facebookized my action in some way. Could we do this?1 point
-
I'm really curious to know where that tools.php is coming from. If you edit your /http404/ page, what template is it using? Is your site based on an existing profile?1 point
-
I agree, but think the "you are a true hero" probably qualifies as a like, or likely something better. I think there is a concern among new users that clicking "like" will send them off to Facebook and post something on their wall. Thankfully it's just a regular like button like those we had before facebook, and has nothing to do with facebook.1 point
-
$new_page->getInputfields(); will get the inputfields in context of a page already and thinks there's images or tries to access them, but there isn't. This has come up a a few times but can't find it. FormTemplateProcessor module by Ryan does the same and suffers from the same problem when using file fields (it's not meant to work with it anyway) https://github.com/ryancramerdesign/FormTemplateProcessor/blob/master/FormTemplateProcessor.module One way around this would be to create the form not using $page->getInputfields() but $page->template->fields and use it to get the inputfield foreach($page->template->fields as $field) { $inputfield = $fields->get($field->name)->getInputfield(null); }1 point
-
I can't seem to make myself use this on the regular basis, but reversing things so you have: if('group' == $page->template) This works well, because if you forget the second = you get an error, rather than php just setting the variable.1 point
-
1 point
-
oh ok. Well, if the breadcrumb always starts with [home icon] > Admin >, then I think the home icon is enough. The "Admin" part states that you're inside the admin, so it makes sense for the home icon to have the "view site" functionality. No need for two buttons, imo. Thanks for clarifying!1 point
-
It's pretty similar to what some email marketing programs I've used in the past do. It's a neat way of saying as the admin "hey, you can play with these toys in any order you want, but we're still controlling all the containers" and it does make for something that's a bit more controllable. It would certainly be of interest I think to people writing blogs or news articles - take an average article from this site for example: http://www.rockpapershotgun.com/2013/10/23/enemy-within-preview/ - text, image, text, image and now and then a video - and it really would allow people to write articles where they like - admin or frontend - and see the layout they'll get as they're writing it. There are other front-end editors of course, but this just looks so simple. Anything like this that makes things like that simpler is going to be great, even if all it is really doing is constricting what you can and can't do - but for news and blogs that's where you don't mind having your layout controlled like that Having said all this, you would have to wrap each bit of content with a div so when you go back and edit it the blocks all come apart nicely, but that's no big deal really unless you're trying to shave off every last byte from your page load. <div class='editor-image'> or something isn't exactly going to ruin your life.1 point
-
Joe, I tested here and all seemed to be working how it should. Then I noticed I had some uncommitted updates pending in my JqueryCollagePlus dir. I went ahead and committed them to a new version. Please give the latest a try and let me know if that fixes it for you?1 point
-
Sir Trevor definitely looks interesting and a great idea. It seems like this could solve a lot of the bad-markup-from-RTEs issue. Though I'm not yet convinced this is better than an RTE for most. At least in testing it out here I found it to be more of a hassle inputting content... though maybe it's just something to get used to. I'm also looking for how to input headlines and not seeing the option to do so--I'm assuming they'd do that with one of the "+" plugins. But it does call into question how clients would go about pasting content in a convenient manner (probably the most common input methods clients use). But this does seem like a good project to keep an eye on.1 point
-
visualcookie please excuse this advice, not trying to be a douchey know-it-all (I certainly don't know anything close to it all), but you can show teppo the love by clicking the Like This button on his post (you probably knew and just forgot in which case ignore this post).1 point
-
1 point
-
@visualcookie: did you insert those paths in that format exactly? As far as I know, you should insert them starting from /site/ (ie. /site/templates/_sitejs/.) Probably something you've already tried, but just making sure1 point
-
Hey guys, The company I'm working for has launched two new pw's recently built with my Spex module, and there are more coming! http://www.deluca.ca/ http://alpine-animal.net/1 point
-
I guess your host has enabled some kind of redis based sessions that clashes with file based one that PW uses. That RedisException is definitely not coming from PW, maybe from phpredis: https://github.com/nicolasff/phpredis/issues/184 One option to think is to install "Session Handler Database" module (comes with PW core) that moves sessions from file based to mysql database. Not sure how the redis sessions work at your host, so not sure if that helps at all. It seems that the host is taking sessions from pretty low level anyways. Which host you are using? Probably only that you do not find sessions files from /site/assets/sessions/ (they go into your hosts redis db).1 point
-
Steve have build some excellent modules for admin security: http://modules.processwire.com/modules/auth2-factor-ppp/ and http://modules.processwire.com/modules/session-login-alarm/1 point
-
Dear Ryan, Why thank you, and you're welcome! Yes, in a way, having three locks on the door feels very much like a New Yorker. But I lived in Manhattan for two years, so there you have it. I'm going to add SessionLoginThrottle. That's a good idea too! Best regards, Peter1 point
-
I think you can enable Cross-domain AJAX requests in your .htaccess # ------------------------------------------------------------------------------ # | Cross-domain AJAX requests | # ------------------------------------------------------------------------------ # Enable cross-origin AJAX requests. # http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity # http://enable-cors.org/ <IfModule mod_headers.c> Header set Access-Control-Allow-Origin "*" </IfModule> found in html5-boilerplates .htaccess1 point
-
1 point
-
Yeah, I think Sir Trevor is closest what I have seen from open source world as a RTE re-imagined. Looks very promising at least!1 point
-
This looks great. Is this something that could potentially be integrated with ProcessWire or with the module you've built?1 point
-
This also seems interesting as maybe also seen: http://madebymany.github.io/sir-trevor-js/1 point
-
1 point
-
Hey guys! Another tiny little PW site we have built in the last few weeks. Really really reaaaaaally small budget, so nothing is really perfect on this website. But the client (a friend of mine, he is a teacher and a hobby author) is happy to now have more control about his content, speaking of his short stories and novels. See for yourself - feedback welcome: http://www.peterhohmann.net1 point
-
Ok, well this will hopefully get you started. I haven't seen much on the forum or the docs about doing this. This code is an adaption from what I have just put together to support repeaters in the page tree migrator module. Because the migrator needs to take the IDs from existing repeaters, convert them to names, and then back to IDs, I think what I ended up having to do was probably more complicated than what should be needed in your situation. It worked perfectly for my needs and from some quick testing I think version should work for your needs, but there might be a much simpler way to do it. You will need to adjust the first three lines, and then the lines under both the //Add fields to.. comments. This code creates the repeater field, the necessary fieldgroup and template, but you would still need to add the actual repeater field to the required template, but I get the feeling you have that sorted already with the code you posted. $titlefield = wire("fields")->get("title"); $bodyfield = wire("fields")->get("body"); $repeater_name = "newrepeater"; $f = new Field(); $f->type = $this->modules->get("FieldtypeRepeater"); $f->name = $repeater_name; $repeater_fg = new Fieldgroup(); $repeater_fg->name = "repeater_$repeater_name"; //Add fields to fieldgroup - add others as necessary $repeater_fg->append($titlefield); $repeater_fg->append($bodyfield); $repeater_fg->save(); $repeater_template = new Template(); $repeater_template->name = "repeater_$repeater_name"; $repeater_template->flags = 8; $repeater_template->noChildren = 1; $repeater_template->noParents = 1; $repeater_template->noGlobal = 1; $repeater_template->slashUrls = 1; $repeater_template->fieldgroup = $repeater_fg; $repeater_template->save(); $repeater_page = "for-field-{$f->id}"; $f->parent_id = $this->pages->get("name=$repeater_page")->id; $f->template_id = $repeater_template->id; $f->repeaterReadyItems = 3; //Add fields to the repeater - add others as necessary $f->repeaterFields = $titlefield; $f->repeaterFields = $bodyfield; $f->save();1 point
-
For those interested for now, I created a github repo along with some description how to install and use it: https://github.com/somatonic/BlocksContent Thanks1 point
-
Sounds interesting. I'll look into this as a future option, as it would make a lot of sense in a single-install, multi-site environment.1 point
-
Good call diogo! Ideally the admin theme should be shared too. Maybe something more like this then: /wire/ /shared/ /modules/ /templates-admin/ /site/ /site-example1/ /site-example2/1 point
-
Hi Matthew, Commas need to be escaped because they are also used to separate fields in the Selector. The correct method is this: $np->title = $sanitizer->selectorValue($input->post->title); You should sanitize all values that you use in a selector like this. Use text(), textarea() when you are outputting your data on the website, e.g. in form fields. Btw you are right, Pw does set a name based on the title if you ommit setting ->name. Cheers1 point
-
I proposed this idea several times already in various threads... right in the repeater thread once it was published. I played with the idea and even tried to work out adapting repeater module, but to no success yet as it gets a lot more complicated than first thought. Since there were no real response or interest I haven't spent more time with it. One try was also to build a block module, but haven't got the time to further develop this and it's in a proof of concept alpha stage, only front-end editing and not backend interface. Searching those seems one of the harder things to solve as it gets complicated, but if using a spider or something it wouldn't be a real problem. Scalability would be another consideration, as I can image people using this then to build vast websites with every block being a page, with repeaters inside resulting in even more pages. You get the idea.1 point
-
I've never come across a client that didn't prefer a rich text editor to the alternatives. The reality is, they like RTEs because it's something they are already familiar with and it's easy for them to use. So I think a better goal is to give them what they want, but place limits upon it so that it can't produce a mess. Just because RTEs+clients can create a mess doesn't mean we have to let them do it. Both our TinyMCE and CKEditor rich text inputfields come very much restrained and prevent the client from creating a mess. CKEditor4 and it's ACF (advanced content filter) seem particularly adept at solving this problem. If you can convince a client to use an LML (Markdown, etc.) or some method of creating content in blocks, then that's fine. But once the next guy comes around showing them "look what you can do in my CMS–it's like using Word", you may be at a disadvantage. Other factors to consider: 1) content maintained by blocks may be significantly less portable through future CMS changes, web service/syndication feeds and such; 2) it may be more difficult to maintain site-wide consistency with the designer's original vision if a site's main content area is a mashup of content blocks. Personally, I would avoid trying to pursue a blocks strategy for most content editors, whether in a CMS that is built around the concept, or via trying to build everything around Hanna Codes. Instead, let the designer do their job and determine consistent and well thought placements for photo galleries, navigation, etc. I see Hanna Code as being better for the exceptions of needing something somewhere, and not something that editors should have to keep as part of their vocabulary.1 point
-
Hi Uliverse, I'm a long time Contao user too and I'm afraid you can't mimic the same behavior as in Contao. The above described ways are workarounds but not the same. In PW you have to be much more clear about your article structure from the very beginning. The advantage is that you have much more control over your markup. In Contao there are many if-than situations you can't foresee and thus not control. This applies mainly to site styling, e.g.a headline may be inserted inline or as a content element resulting in two different markup situations. Give PW a try. It is much more flexible in its own way than Contao. EDIT: This is possible, but repeaters are sticked as "fields" to their template. Let's say you'll have three different kinds of repeaters each of which with another order of fields or different fieldtypes at all and you want your editor to be able to choose from each of the three options on any page. In this case you'll have to attach all three repeaters to any template edtiors may use. Anyway, the described scenario is the one that comes closest to Contao. At least, as far as my understanding reaches.1 point
-
1 point
-
Great tutorial Soma! This is the best summary of using PW's Inputfields that I've seen. I noticed you did $field->attr('id+name', 'email') so just wanted to explain what that is for those that may be unsure of the syntax. That syntax is basically saying to set the 'id' and 'name' attribute to have the 'email'. While every field needs a 'name' attribute (like in HTML) the 'id' attribute is optional… if you don't assign an id attribute, PW will make one up. If you intend to custom style a field with CSS or target it from javascript, then it's best to assign your own 'id' attribute. Otherwise, it doesn't matter. // this… $field->attr('id+name', 'email'); // …is the same as: $field->attr('id', 'email'); $field->attr('name', 'email'); // …as is this (direct reference): $field->id = 'email'; $field->name = 'email'; The advantage of using the attr() function over direct reference is that attr() can't ever collide with other Inputfield properties that might have the same name as a field attribute. It's basically your way of saying "this should definitely be an HTML attribute and not anything else." For recognized attributes like 'name' or 'value' it doesn't matter what syntax you use because an Inputfield already knows 'name' and 'value' are standard HTML attributes. But if you needed to add a custom attribute like "data-something", well then you'd definitely want to use the attr() method of setting. That attr() method should only be used for things that would actually be HTML attributes of the <input>, because they will literally end up there. So if you do an $field->attr('label', 'Hello'); you'll end up with an <input label='Hello'> in the markup, which is obviously not something that you want. That's why you assign a non-attribute property like 'label' or 'description' directly, like: $field->label = 'Something'; Last note about $attr() is that it can be used for both setting and getting attributes: $field->attr('value', 'something'); echo "The field's value is: " . $field->attr('value'); // same as: $field->value = 'something'; echo "The field's value is $field->value"; To extend your example, lets say that you wanted the 'email' and 'password' fields in a fieldset titled "About You". You would create the fieldset, and then add/append the fields to the $fieldset rather than the $form. Then you'd add the $fieldset to the $form: $fieldset = $modules->get('InputfieldFieldset'); $fieldset->label = 'About You'; $field = $modules->get("InputfieldEmail"); $field->label = "E-Mail"; $field->attr('id+name','email'); $field->required = 1; $fieldset->append($field); // append the field $field = $modules->get("InputfieldPassword"); $field->label = "Password"; $field->attr("id+name","pass"); $field->required = 1; $fieldset->append($field); $form->append($fieldset); Or lets say that you wanted those 'email' and 'password' fields to be each in their own column so that are next to each other horizontally rather than vertically. You would assign the 'columnWidth' property to both the email and password fields. In this case, we'd give them both a value of 50 to say that we want them to be a 50% width column: $field->columnWidth = 50; To jump out of tutorial mode and into idea mode: lately I've been thinking that PW should have a YAML to Inputfields conversion tool in the core (something that would be pretty easy to build), so that one could define a form like this: And create it like this (where $yaml is the string above above): $form = $modules->get('InputfieldForm'); $form->load($yaml); echo $form->render();1 point
-
As our studio is getting close to finishing another project, we are facing the challenge to provide our client with easily understandable materials or kind of a manual on how to manage content in PW. As I guess that this happens from time to time to you guys around here, too, I wonder if it would make sense to collaborately work on a kind of manual document explaining key actions to be done for an editor. So there could be an open document or wiki providing texts in different languages and supportive images we all could use to e.g. turn it into a nice PDF or printed handbook (yes, some clients still like paging through paper) where we just have to replace images. I don't think this work has to be done over and over again by each one of us for his own purpose. And I'm sure, all our clients would benefit from something like this. Also it would be a nice plus for everyone thinking about using PW the first time for a client project.1 point
-
The source files themselves are in English, so the only time translation files are needed is if you want to change them (whether changing the language, or changing the English). I could maintain an English translation pack (with unpopulated fields), though it would be something that would only be useful as a starting point for other language packs. Still, if that would be helpful to other people, I'll be glad to do it.1 point
-
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?1 point
-
I wanted to add a note about exceptions on the front end. If you want to abort a request, throw a WireException: throw new WireException('your error message'); That message will automatically go into the errors.txt log and email the site administrator. If the site is in debug mode or you are a superuser, it will report the error message to you as well. If not debug mode and not superuser, the user will get a generic "an error occurred, administrator has been notified" message. Another exception you can throw is the 404. This will make PW display the 404 page (from your site tree) and send the proper 404 headers to the browser. PW doesn't interpret this as an error that needs to be logged or emailed. throw new Wire404Exception('page not found'); This is the exception you might want to throw if you get an unrecognized URL segment, for instance.1 point
-
Marc, when you are developing a site it's good to turn debug mode on. This will ensure that errors are sent to the screen, exceptions reported, etc. This can be found in /site/config.php. By default, it is false. You'll want to change it to true: $config->debug = true; Obviously you don't want this enabled for production sites, so remember to change it back to false for live/production sites. I don't see any problem with using var_dump, var_export, print_r, etc. so long as you are directing that output to where you can see it. Also avoid running these functions on PW objects as you may get into an infinite loop. Sometimes it can be difficult to track the output of these functions because PW performs a redirect after most POSTs. But if you use PW's built-in reporting functions, they will get queued between requests until they are output. Here are the relevant functions bellow. They will produce the messages that you see at the top of your screen in PW admin: $this->message("status message"); $this->message("status message that only appears in debug mode", Notice::debug); $this->error("error message"); $this->error("error message that only appears in debug mode", Notice::debug); If you are outside of a Wire derived object, you can call upon any API var to handle the notice for you. For example: wire('session')->message('status message'); wire('pages')->error('error message'); Note that these reporting functions above are for the admin (and related modules), and they don't do anything on the front-end of your site. How you choose to debug or report errors on the front-end is at your discretion. Personally, I keep debug mode on in development, and this puts PHP into E_ALL | E_STRICT error reporting mode... it reports everything possible. If I need to examine the value of something on the front-end, I'll do it the old fashioned way with just PHP. Though others may prefer to go further with their debugging tools. If you want to keep your own error log, here's how (anywhere in PW): $log = new FileLog($config->paths->logs . 'my-log.txt'); $log->save('whatever message you want'); You can direct it to store logs wherever you want, but I suggest using the PW logs dir as shown in the example above. This will make the log appear in /site/assets/logs/, and this directory is not web accessible for security.1 point