netcarver

That's a long command - wouldn't be surprised if something is timing out. How long does it take from submitting the url to seeing the problem message - between 5-8 minutes or does it appear sooner?

@joer80 How much processing is going on? How long does it take? What timeout are you telling curl to use?

@Sinmok Take a look at what Gayan posted above, it shows you how to do it. I've also updated my previous example to make it more obvious.

Hi Gerhard, could you add the link to your post above?

This looks similar to (but a little simpler than) pagination to me. Have you tried a straight pagination solution to this? Otherwise, something like this might do if you don't need access to the $page objects themselves... $list = $pages->find('whatever'); $titles = array(); foreach ($list as $p) { $titles[] = $p->title; } $chunked = array_chunk($titles, 3); print_r($chunked); Even simpler, plus you get access to the object with all its data; $list = $pages->find('whatever'); $chunked = array_chunk($list->getArray(), 3); // Output plaintext titles by iterating over chunks and pages in chunks. // Access protected fields as needed using $page->fieldname and format as required. foreach ($chunked as $i => $chunk) { echo "Chunk $i\n"; foreach ($chunk as $page) { echo $page->title, "\n"; } }

Just want to point out that the code diogo posted in #17 uses a relatively new PHP array syntax. If you are running PHP < 5.4 then you will need to do this instead... $images = array("image1.jpg", "image2.jpg", "image3.jpg");

Sorry n0sleeves, I have no ideas for you. Have you tried posting on the Manjaro forums or asking about this in #httpd on freenode?

And the value (if any) of 'AccessFileName' in your config file?

What is the value of 'AllowOverride' in your apache config file?

@pwired Is there a particular reason for this? I'm with diogo on this one. I went through a phase of wanting to put everything as tersely as possible in PHP but I don't do that any more. I find single liners make it more difficult to see structure (where's the closing brace for the if statement in diogo's example above?), more difficult to read, more difficult to debug (especially if you single step with a debugger), more difficult to edit and more difficult to maintain than using multiple lines. Vertical space in a good text editor is almost unlimited - and easily navigated around. I'd rather pay the price of a few more lines of code to be able to instantly see the structure, closing braces and be able to step through the code line-by-line.

@Manaus Thank you for posting your code - I learnt something from it about PHP alternative control structures today!

Hmm. Not only have I been obtuse today but my eyes are now playing tricks on me as I've downloaded your pastebin file so I can search it locally and I can't find the line your editor is highlighting as a problem in the pastebin version at all. In the image you posted above you are doing an include of a footer file followed by output of a HTML5 footer - so perhaps that explains why you were seeing a double footer on the site (which I can't see from here at the moment BTW.) Anyway, I see your feed is validating so I'm guessing this is now fixed. Please let us know!

Err, dare I creep down and suggest searching your installed files for "<!--/#content-->"? /netcarver shoots back up to safety.

Hah, have to laugh at myself as there is a more probable cause which I totally overlooked and you even opened your topic with it! Ignore the above diatribe - it's only applicable if the tags are being closed right - which I now see is the point you were making. I'll leave the embarrassing reply above as it might help someone else out one day. In the meantime, I'll swing back to my tree to consider a suitable penance for being obtuse.

Ok, I can't tell you which file to edit; I simply don't know but I have seen problems like this in the past and they were either due to byte-order-marks* that were being saved by someone's editor as it wrote out the a PHP file or some whitespace at the beginning or end of a PHP file that is being output as part of the feed where it isn't valid to have it in XML. I can't guarantee that either of these are the problem in your case but then again, perhaps they are. Anyway, here are some clues as to what to do to find out... Grep your PW installation - particularly modules and your own templates - for "?>" near the end of files. If there is HTML following the "?>" then it is needed - if there is only what appears to be whitespace remove the ?> to the end of the file and save the file. Sometimes people put ?> at the end of their PHP files and don't realise that *any* whitespace following the ?> tag will be output verbatim as part of the output stream by PHP. Re-save each suspect file from an editor that you can configure to save as utf-8 and not to save with the Byte-order-mark. (Notepad++ on Windows is one good candidate.) * Covers one troublesome aspect of BOMs. The other is that if they appear at the start of your PHP file, before the "<?php" then even though they might be correctly handled by your code editor, PHP can emit them as part of the output stream as it appears before the start of PHP interpretation. If the PHP file is building a feed then the invisible BOM is emitted straight into your XML - probably invalidating it. Anyway, that's the mental model I had of this when I ran across something pretty similar to this a few years ago and managed to fix it - I might be wrong though - in which case I await correction with anticipation.

First off, shouldn't the switch to PHP be "<?php" ?? After that, are you sure your code example is complete? I've never seen that form of if statement used without a switch back out of interpreted PHP straight after it. Have you cropped things out to simplify your example by any chance? After looking at alternative control structures that looks ok. The other thing to check is that your $myfile string is case-for-case the same as the filename that gets written into the name field as I think the comparison is case sensitive.

@cmscritic, The message I'm seeing there says "Error has been logged." What are you seeing in your error log?

One approach might be to add an extra field to the user template, something like "sso_hash" and have your sso login handler compare against that field. You'd also need it to take similar actions to the ProcessLogin.mondule ___execute() routine in order to setup the session if successful. If your customer ever wants to allow direct login via PW's login form then they'll have to (at some point) provide you with the un-hashed, raw, passwords for users so that you can set PWs password field with its correctly hashed version of the password. You may want to ask if they will ever be willing to do this because, if they aren't, you may as well use the sso hash as the user password and just live with the double hashing.

@blackeye1987 Thanks for posting. Like adrian, I'm not sure I understand what you want to do. When you say "I receive the password already hashed" do you mean that this sso system does its own hashing on account creation and at login and passes those password hashes through to the app (PW in this case) and that you just want to do a compare of their login hash with whatever you stored as the hash verbatim?

Would making this hookable open file-uploads up to storing outside the site-root too? If so is just adding a checkbox to InputfieldFile to control adding the fixed string to the path going to be enough or should a more flexible scheme for modifying the path be attempted from the outset?

@Gerhard, You are right - I used the words "hard coded" incorrectly. I meant that it's set in the render routine. My point still stands though; why have it set in the render routine at all? Couldn't it have a default value (translatable, yes) but otherwise it should use the label that the owning code assigns to it - so that it can be used in many different forms, potentially with a different label in each. You can probably solve your issue by translating the string - but that doesn't mean the root problem is fixed (I use the term "problem" here lightly, Ryan might have a very good reason for setting the label in the render method!)

@blad Yeah, it's logical but there are actually two different use-cases and I was getting them mixed up. I think Gerhard touched on the difference between the two above; the admin login only needs to collect the username and one copy of the password, so it uses InputfieldText with the type set to 'password' to do it. In admin forms (once logged in) if you collect a password to set it or change it, then you usually get two copies (the password and a copy of the password) - just to make sure you typed it the same both times. I think (but didn't realise till now) that InputfieldPassword is for the second scenario; setting or changing a password. Gerhard's trying to reuse this Inputfield in his form but the hard-coded set of the label in InputfieldPassword's ___render() routine is getting in the way. Anyway, that's my current understanding of the situation.

Gerhard, Could I tempt you to add this as an issue on github to see what Ryan has to say about having the label hard-coded into the __render() routine? There might be a reason for it - but it does rather limit the inputfield at the moment.

Great, thank you. This will definitely get noticed by Ryan now.

Well, thanks for the props but that might not be the case. A better solution to the problem might be found in either removing the hard-coded label set from the ___render() routine or in doing what PW does for its own admin login: use an InputfieldText rather than an InputfieldPassword! Here it is straight from ProcessLogin.module... $this->passField = $this->modules->get('InputfieldText'); $this->passField->set('label', $this->_('Password')); // Login form: password field label $this->passField->attr('id+name', 'login_pass'); $this->passField->attr('type', 'password'); $this->passField->attr('class', $this->className() . 'Pass'); First time I've noticed that the login page isn't using InputfieldPassword. Any mileage in that approach for you Gerhard?