celfred

Here's where I am : - Updated to PW 2.6.1 -> The problem still happens. - I added the line you told me. Here's the result : #0 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Selectors.php(318): Selectors->create('bc', '', '') #1 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Selectors.php(115): Selectors->extractString('bc') #2 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Selectors.php(104): Selectors->setSelectorString('bc') #3 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Pages.php(203): Selectors->__construct('bc') #4 [internal function]: Pages->___find('bc', Array) #5 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(387): call_user_func_array(Array, Array) #6 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(325): Wire->runHooks('find', Array) #7 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Pages.php(310): Wire->__call('find', Array) #8 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Pages.php(310): Pages->find('bc', Array) #9 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Pages.php(325): Pages->findOne('bc') #10 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/site/templates/pages2pdf/_footer.php(11): Pages->get('bc') #11 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/TemplateFile.php(169): require('/data/web/d9/a9...') #12 [internal function]: TemplateFile->___render() #13 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(387): call_user_func_array(Array, Array) #14 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(325): Wire->runHooks('render', Array) #15 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/site/modules/Pages2Pdf/WirePDF.module(244): Wire->__call('render', Array) #16 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/site/modules/Pages2Pdf/WirePDF.module(244): TemplateFile->render() #17 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/site/modules/Pages2Pdf/WirePDF.module(182): WirePDF->getMarkup('markupFooter') #18 [internal function]: WirePDF->___initPDF() #19 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(387): call_user_func_array(Array, Array) #20 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(325): Wire->runHooks('initPDF', Array) #21 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/site/modules/Pages2Pdf/WirePDF.module(143): Wire->__call('initPDF', Array) #22 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/site/modules/Pages2Pdf/WirePDF.module(143): WirePDF->initPDF() #23 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/site/modules/Pages2Pdf/Pages2Pdf.module(497): WirePDF->save('/data/web/d9/a9...') #24 [internal function]: Pages2Pdf->___createPDF(Object(Page), NULL) #25 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(387): call_user_func_array(Array, Array) #26 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(325): Wire->runHooks('createPDF', Array) #27 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/site/modules/Pages2Pdf/Pages2Pdf.module(317): Wire->__call('createPDF', Array) #28 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/site/modules/Pages2Pdf/Pages2Pdf.module(317): Pages2Pdf->createPDF(Object(Page), NULL) #29 [internal function]: Pages2Pdf->___download(Object(Page)) #30 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(387): call_user_func_array(Array, Array) #31 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(325): Wire->runHooks('download', Array) #32 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/site/modules/Pages2Pdf/Pages2Pdf.module(99): Wire->__call('download', Array) #33 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/site/modules/Pages2Pdf/Pages2Pdf.module(99): Pages2Pdf->download(Object(Page)) #34 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Modules.php(464): Pages2Pdf->ready() #35 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Modules.php(553): Modules->readyModule(Object(Pages2Pdf)) #36 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/ProcessWire.php(315): Modules->triggerReady() #37 [internal function]: ProcessWire->___ready() #38 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(387): call_user_func_array(Array, Array) #39 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(325): Wire->runHooks('ready', Array) #40 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/ProcessWire.php(347): Wire->__call('ready', Array) #41 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/ProcessWire.php(291): ProcessWire->__call('ready', Array) #42 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/ProcessWire.php(291): ProcessWire->ready() #43 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/modules/Process/ProcessPageView.module(227): ProcessWire->setStatus(4) #44 [internal function]: ProcessPageView->___ready() #45 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(387): call_user_func_array(Array, Array) #46 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(325): Wire->runHooks('ready', Array) #47 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/modules/Process/ProcessPageView.module(152): Wire->__call('ready', Array) #48 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/modules/Process/ProcessPageView.module(152): ProcessPageView->ready() #49 [internal function]: ProcessPageView->___execute(true) #50 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(387): call_user_func_array(Array, Array) #51 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(325): Wire->runHooks('execute', Array) #52 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/index.php(241): Wire->__call('execute', Array) #53 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/index.php(241): ProcessPageView->execute(true) #54 {main} Error: Exception: Unknown Selector operator: '' -- was your selector value properly escaped? (in /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Selectors.php line 281) #0 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Selectors.php(318): Selectors->create('bc', '', '') #1 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Selectors.php(115): Selectors->extractString('bc') #2 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Selectors.php(104): Selectors->setSelectorString('bc') #3 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Pages.php(203): Selectors->__construct('bc') #4 [internal function]: Pages->___find('bc', Array) #5 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(387): call_user_func_array(Array, Array) #6 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(325): Wire->runHooks('find', Array) #7 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Pages.php(310): Wire->__call('find', Arra This error message was shown because you are logged in as a Superuser. Error has been logged. And here's my very limited analysis and what I managed to do and understand : - #10 is trying to get the page from my urlSegment2 string. I've noticed the call to the _footer page and remembered having the 'Print footer' option enabled in my pages2pdf module. I unchecked the option and.... tada! It works! My _footer.php page contains : <?php echo 'page générée le '.date("d/m/y \à h:i:s"); ?> So I figured out that maybe the problem would be in the pages2pdf module : shouldn't it call the Pages->get('name=urlSegment2') instead of Pages->get('urlSegment2')? Actually I may be totally wrong on that since much of this is way over my head, but I'm trying (hard, I promise ) to understand why this happened. Anyway, THANKS for your help since I can now make it work (loosing my footer is no big deal). An afterthought : I wondered why it worked on my localhost... I was using pages2pdf 1.1.1 (and 1.1.5 on the remote). Maybe an explanation?

PW 2.5.3 and I've just ticked the 'Allow URL Segments' box. Settings are the defaults, I guess. (and no pagination) As I mentionned earlier, it works on my localhost. Maybe that could help, but I have no idea what to do with that... What is really weird is that I have other pages that work perfectly (with strings). The only difference I can notice is that here, I'm using 3 urlSegments. By the way, thanks a lot for your help.

Actually, I thought as you say at first and struggled a couple of hours trying to isolate the code that triggers the error. I finally emptied my target page with just a : <?php echo 'test'; ?> But the error remained and it IS triggered by this call. As I mentionned in my first post, if I manually type '123' (or whatever number) in place of my urlSegment2, it works as expected. If I manually type '6bc' (or even 'bc') in my url, it throws the following error message : Error: Exception: Unknown Selector operator: '' -- was your selector value properly escaped? (in /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Selectors.php line 247) #0 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Selectors.php(284): Selectors->create('bc', '', '') #1 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Selectors.php(81): Selectors->extractString('bc') #2 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Pages.php(165): Selectors->__construct('bc') #3 [internal function]: Pages->___find('bc', Array) #4 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(389): call_user_func_array(Array, Array) #5 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Wire.php(344): Wire->runHooks('find', Array) #6 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Pages.php(260): Wire->__call('find', Array) #7 /data/web/d9/a9/72/planetalert.tuxfamily.org/htdocs/wire/core/Pages.php(260): Pages->find('bc', Array) #8 /data/web This error message was shown because you are logged in as a Superuser. Error has been logged. While writing this message, I've just tried manually entering '123' in the adress bar of the navigator, and it works right away, echoing my 'test' line in my PDF file... If I type a string (any character), it throws the error...

Hello to the community, I'm facing a rather weird issue on my PW site with the pages2pdf module and urlSegments. Maybe one of you will help me figure this out. I have this code : // PDF Download link if (!$input->get['pages2pdf'] && $user->isSuperuser()) { echo '<a class="pdfLink btn btn-info" href="' . $page->url.$input->urlSegment1.'/'.$input->urlSegment2.'/'.$input->urlSegment3. '?sort='.$sort.'&pages2pdf=1">Get PDF</a>'; } My urlSegments are as follow : 1='all', 2='6bc', 3='12345'. In other words, I want to generate a PDF file listing 'all' events recorder for the team '6bc' during the time period id '12345'. It all works fine on my localhost site, but when I am online, I get an 'unknown selector' error instead of my PDF file. I have managed to find out that if I replace my urlSegment2 with an integer value, it works ! Why and how is this possible, I have absolutely no idea... I have other pages on my site where it all works fine with strings... I wonder, then, if I shoud go and replace all of my 'logic' : use query strings instead of urlSegments? Anyway, if anybody could give me a clue to solve this issue I would greatly appreciate Thanks in advance.

Hi there, I'm still facing a little issue with the new updated version of this module. If I set NO limit when fetching data, I have an automatic limit set to 25, although my maximum amount in the configuration page is set to 50. If I set 'limit=0' in my request, it 'works', it fetches ALL data (event though I set my maximum amount to 5, for example). So it's not a big problem since I can manage my limit manually so it is consistent, but I wonder if that's the expected behavior... To me, the maximum amount should override any manually set limit, and if no limit is set, then the maximum should be the limit. I mention it since it caused me a little trouble on my site. Maybe someone will find this useful

Thanks for your answers (and for the title update). I am definitely not at ease with the synchronizing between dev environment and live environment... I guess I'll try little by little following your advice and see how it goes

Hi there, I'm trying to add multi-language support to my site. The site is already online and the database gets changed everyday. On my localhost dev, I looked at adding the multi-language support and noticed that it altered the database by adding new fields. Hence my newbie question : how shall I operate? I understand that I should keep modifying my database on my dev branch by adding the full multi-language support, but how will I eventually throw this online without loosing the new database updates happening in the meantime? For the moment, on my localhost, I've installed a fresh PW brand new version, I have imported my freshest database backup, I've changed many things (templates, modules, adapted some code so it works with my new PW version), and now I want to tackle this multi-language issue. But see, I haven't touched the database in my previous changes so far, so I wasn't too worried about throwing it all online again, but now, that's a different story to me So if you have a little time to point me towards the good direction, that'd be great! Thanks! Edit : SORRY for the forum admins, I've just noticed my wrong topic line : Upgrade an existing single language WEBSITE (not file) with multi-language new version. And I can't seem to have the possibility of editing it myself...

Thanks for the help. Actually, after testing it didn't work. So here's what I did : I checked the $info['name'] content and it returned 'ProcessPageSearch', so I changed your line with if($info['name'] != 'ProcessPageSearch') throw new WirePermissionException($this->_('You do not have permission to execute this module') . ' - ' . $class); It works now! But maybe I've broken something doing this ?

Hello all, Sorry to come back on this issue, but I have upgraded just about everything on my site and the only thing that prevents me from putting it online is this issue about being logged in as 'admin' to be able to use the ServicePages module I keep trying to understand, but I must admit this is (again...) way over my head, and I can't find a hack to this. If you're a 'guest', you just don't get to see anything on my site, which is a little dissatisfying As I said, I've tried the 'page-edit' to 'page-view' switch in ProcessPageSearch, but it didn't work and I can't firgue out what else to try. I've tried to understand the getModule call with the 'noPermissionCheck' option, but it's over my skills... So if anyone has a little time to help me, I would greatly appreciate! Thanks in advance.

I've tried the quick fix mentionned above by jiobazzard but it didn't work I still have to login as admin to be able to use ServicePages as expected (with PW 2.5.3 on localhost). I've tried emptying my cache too. Here's the error I get : Error: Exception: You do not have permission to execute this module - ProcessPageSearch (in /home/celfred/PlanetAlert/wire/core/Modules.php line 840) If anyone has another suggestion...

Wow.... I've just tested what you said and .... THANKS a lot. This works fine and I guess I could have struggled many more days without finding it myself... I've used the second solution . And now I can go on with my little project, cool! Thanks again for your great explanations and answer.

Hello all, I'm back on my PW site and I'm facing an issue for a couple of hours now and it's driving me crazy... I'm sure it's not that much for a bunch of you, but it looks hopeless to me so here's my problem : I'm sending a form to a page and I have many checkboxes sent, so I used an array. My code looks like this : <table class="adminTable"> <tr> <td></td> <th ng-repeat="task in tasks" title="{{task.summary}}"><div class="vertical-text"><div class="vertical-text__inner">{{task.title}}</div></div></th> </tr> <tr> <td></td> <td ng-repeat="task in tasks" title="Tout cocher"><input type="checkbox" /></td> </tr> <tr ng-repeat="player in players"> <th>{{player.title}}</th> <td ng-repeat="task in tasks" title="{{player.name}} - {{task.title}}"> <!-- <input type="hidden" name="player[{{$parent.$index}}]" value="{{player.id}}" /> --> <input type="checkbox" name="player[{{player.id}}][]" value="{{task.id}}" /> </td> </tr> </table> The important line (to me) is the <input type="checkbox" name="player[{{player.id}}][]" value="{{task.id}}" /> in which I'm trying to pass both the id of the player and the task id to record for the player. All this is embedded into an ng-repeat loop since I'm using AngularJs... Anyway, the variables look ok when I'm looking at the generated source and in fact it look fine if I print_r($GLOBALS) when I recieve the POST variables. Here's the print_r($GLOBALS) result : [_POST] => Array ( [adminTableSubmit] => Enregistrer [player] => Array ( [5157] => Array ( [0] => 1580 [1] => 1578 ) [5171] => Array ( [0] => 1580 [1] => 1578 ) ) ) (2 players and 2 tasks for each) BUT : if I write $checked_players = $input->post->player; I get an empty array! Indeed, trying to debug my thing (I guess I can call it a 'thing' at this time), I type : foreach($input->post as $key => $value) echo htmlentities("$key = $value") . "<br />"; $checked_players = $input->post->player; print_r($checked_players); and here's what I get : adminTableSubmit = Enregistrer player = Array Array ( ) Whereas I keep thinking my print_r($checked_players) should return : [5157] => Array ( [0] => 1580 [1] => 1578 ) [5171] => Array ( [0] => 1580 [1] => 1578 ) so that I could then work with that and save data as pages... So please, what I am doing wrong? I'm sure I'm messing things up. I've tried so many possibilities and nothing has worked so far. Hence my message to the community. I really don't get it since it seems like such a basic problem... but the facts are there : I'm stuck Hope to hear from one of you soon. Thanks in advance for your help PS : Sorry for my long post, but I'm trying to be as clear s possible.

Hello, Maybe this way...? http://tanakahisateru.github.io/js-markdown-extra/ http://michelf.ca/projects/php-markdown/extra/

There's also : http://www.codingame.com/ (for Javascript, and many other languages).

@kongondo Thanks for this follow-up. Fredi doesn't reveal the link to Admin. You're right. I'm just imagining a case when a user would try to go through anyway. If it is default PW installation, he could try and type '/processwire/' in the URL and if Fredi is used, then the user has page-edit role, so he can see the whole website tree (he can't modify it). But he can see, for example, names of other members, totla number of members and so on... Which, in my opinion, he shouldn't. Anyway, I don't want to 'polllute' quickjeff's post If this discussion has sense, maybe it should continue in my previous post or in Fredi's module discussion. And I guess Ryan answered this as well :

Hi there, @quickjeff : Sorry for my message that may seem off-topic for you, but I think kongondo answered your questions already and pointed you in the right direction (as always with kongondo!) @kongondo : I'm jumping on your answer pointing to using Fredi. I guess you have to give a page-edit permission to members (at least on the fields you want the user to be able to modify) and what then if the member hard-code the url to get to the admin panel (for example by adding /processwire/ _by default_ to the homepage). He'll have access to the back-end and see everything (without being able to modify things, of course). Is there a way to use Fredi and block the access anyway? Or is this something that I care about and that I really shouldn't because it's a "false" issue? Thanks

Thanks a lot SiNNuT for this answer. I guess I'll pull up my sleeves and try to code some basic front-end editing tools and keep my members out of the PW back-end... Actually that's what I started doing, but when I saw Fredi's possibilities, I thought "Well, I'll never be able to do as good as this in terms of sanitizing data, so let's use it!" and that's when I got stuck with the page-edit permission needed for Fredi's access and page-edit permission giving too much 'view' power in the PW back-end. Again, if someone can try to explain to me why giving page-edit permission to a role allows full access to the website tree in the PW back-end and not just access to the branches where the page-edit permission applies (I tried to use the Page Edit Per User module to limit), I feel like I would understand things better, because I'm a little lost on that I have a feeling I should interpret things this way : "By default, only the 'Superuser' has access to the PW back-end. If another user is given access, this user can see ALL of it (from /, and all branches) but actions will be limited according to his permissions (the buttons 'view', 'edit', 'move', 'delete'... will be there or not. If the user has no permission on a page, no buttons are shown, but the page title is there anyway. And it works this way because ... [and that's what I'd like to understand;)]". To be as clear as possible, on my screenshot, I'm logged in as 'celfred' having the 'member' role : I have the 'edit' permission on my branch : cool. But as you can see, I also can see the other members and see how many invitations they have and the dates). Since I have no permissions in those branches, I feel like they should be hidden... I've read many posts in the forums about roles and permissions and I have a little question : when you have a huge website (as some of you do) with thousands of pages and you have multiple roles. Do the users have access to hte thousands of pages anyway (even though they can't edit them)? Let's say for example on the Blog profile site. If a user can edit articles in 1 category only, does he have access to all categories? If all other categories could be hidden, I could imagine 'very basic' admin back-end for certain users and 'more complex' back-end for higher-level users... Anyway, for the moment, I'll go ahead and leave the users with just the 'guest' and code something in the front-end, as SiNNuT mentionned above Sorry if you feel like I misunderstanding things about the PW back-end access... I'm trying my best to make sense out of this so I can have a correct approach. Maybe those 'roles' and 'permissions' issues are for bigger sites, not really useful for my amateur very small sites

Hello there, I'm struggling again with a new site I'm trying to implement for fun. First, for personal use, but now I'd like to make it a 'member available' site. The site is just an invitation management site : who came over? What did they eat? What ere the recipes? And so on... Here's my problem : I'm trying tp use Fredi (the module) to allow members to edit their recipes, their hosts, their profile. Actually, I wanted to use Fredi so I didn't have to really care about anything front-end. Fredi would take care of it. I added a 'member' role (with page-edit access) to each member. It works fine this way, but the worry I'm facing is that if a member manually adds '/processwire' in the address bar, he will have access to all the members list and invitations and I wish I could hide all of this. Actually, they can't 'View' or 'Edit' anything, so I guess the probability of them fiddling with all these information is close to zero, but I do'nt like it anyway. I wish they could have access ONLY to their stuff. In my tree, this means everything under '/invitations/user-id', 'guests/user-id/', and '/dish/user-id'. And I'm unable to find out how to do this... Hence my post The other way I imagined : leaving all members with 'guest' role (if they type 'processwire' in the address bar, they won't see anything (which is good), and implementing front-end editing solutions for the members. It could work, but I feel like I'll never use the user/roles PW capabilities if I start working this way Am I misunderstanding something? If anybody could give me a clue about how to handle this issue, I'd appreciate

Thanks and congratulations for your work, Ryan! And another big thanks to the whole community and the most implied users who give us so many useful advice... It is really a fantastically efficient community and I guess they all deserve a part of the thank yous for this new version

I had the same issue and hard-coded the url pointing to the asset file (using the id and basename fields)... Actually, it seemed like a workaround to me. Getting a url from the module would be much better, but I couldn't firgure out how to do that :-(

Well... I feel a little proud, then ;-) And I'm happy I was able to contribute a little. I so often 'take' from all of you without being able to 'give'... Glad I helped!

This website is just... amazing! Congratulations MadeMyDay! I liked the idea of the search field at the bottom. I feel like not having seen that often and I think it's pretty cool. One small remark : when I hide the sidebar on the right, I get a horizontal scroll at the bottom which disappears when I open the sidebar (Firefox 25, on a 16:10 portable computer 1200x800). This happens also when I go fullscreen.

Hello, I'm coming back on the issue of a request returning a '500 internal error' but working if we add 'debug=1' to it... From what I've understood so far, the remote PHP version not really up to date is the cause, but I must admit it's way over my head (and I can't change the remote version) but here's my situation (and I hope there's a solution) : - I'm trying to deploy my local site on a remote server - I found out my 'password hash' problem is coming from the different PHP versions (Up to date on localhost, but 5.3.3... on remote). I managed to solve this. - My site is making a strong use of the Page Service Module all all my request ended in a 500 internal Server Error. - I ended up here and found that adding 'debug=1' helped me getting rid of my errors : cool! - BUT : the response is not in the same form as usual (without debug) and I'm stuck by being unable to treat it accordingly! I used to do : load: function(team) { if (team) { var url = "service-pages/?template=player&sort=title"+team+"&debug=1"; // Added debug=1 to skip the 500 internal error var promise = $http.get(url).then(function (response) { return response.data.matches; // USED TO WORK, but no more... }); } return promise; I have no idea how I can solve this issue... Just in case you wonder where my code is from : it's inside an AngularJs service. Thank you for your help ;-) Edit 01 : Well, I re-read the whole topic trying to understand... and I tested Pete's answer about headers and... it worked, but I really don't know why... Just so you know, I use Firefox 25. I'm worried to know if it'll work with other browsers... If it can help others : I changed line 236 in the ServicePages.module file : Original line : else header('Content-Type', 'application/json; charset=UTF-8'); New line : else header('Content-Type: application/json'); Anyway : thanks Pete! And if someone can take the time to explain why this manipulation is needed, I'd appreciate! Still thinking : if other browsers need different headers, would there be a way to specify this in the same place in the file (like if browser is IE, then send such headers, if it's Firefox, send this one...)? Edit 02 : Me again... I keep reading about those headers... and tried a couple of things and here's what I got I just changed syntax in line 236 mentionned above : Doesn't work : else header('Content-Type', 'application/json'); WORKS ! else header('Content-Type: application/json; charset=UTF-8'); I checked the PHP manual about the header function and I thought maybe the second parameter in the original line in the module is interpretated as the 'replace' parameter they talk about in the documentation... It it makes sense maybe the line should be changed in the module? I actually have NO idea if what I'm saying makes sense. Maybe all this is obvious to everyone here, but I kept stuck on that for a few hours today ;-)

Hello ioio, Welcome to the ProcessWire community! Don't be afraid of messing the admin part of ProcessWire as long as you touch templates in the site/templates/ directory of your installation. You can indeed use the same names head.inc and foot.inc even though you change all their content. The Admin part is left clean because it resides in the wire/ directory and you don't want to touch this one ;-) Actually, this is my first answer to someone's question! No doubt another member of the community will provide you with useful recommendations. Hope I helped ! EDIT : Woa... You guys are so fast...

Woa... I'm always astonished by how you guys can put things up so quickly and simply... I guess it's exactly what I need! THANKS adrian!