ryan

I agree with Soma on all points. The first thing I would try is his suggestion to drag/sort the last page to the first spot. That would force it to re-populate the 'sort' field from all the pages in the list. But if that doesn't do it, I think a table repair would be the next step. Any time MySQL is producing some unexplainable behavior, a repair is a good way to go. But luckily that's not often.

I'm still not sure I'm understanding this. Are you talking about a Page reference field, where you've set the PageAutocomplete as the Inputfield? That's the only autocomplete instance that is built into PW. But even if we're talking about that, I'm not sure how that connects to the URL? Is it possible we're talking about a web browser behavior rather than PW one?

That's good to hear. From what you say, it sounds like LiteSpeed is a good web server to use with PW because it is so Apache compatible.

The behavior you see here where sometimes it allows commas and sometimes it doesn't is because it depends on what other characters are in the strong. So it'll let a comma stay in "test, test2" but not "guns n' roses, mötley crüe". It's a little too strict, and this function could be a lot smarter, so I'm working on some updates to it that I'll post later this week.

Thanks for sending me the profile Seddas--I will take a look and fix. I did actually just commit some updates earlier today that may possibly resolve this particular issue, but since I was focused on fixing another issue, I think there's only a 50% chance of that. So I will be testing this soon.

Thanks for the good description on the issue there. I finally understand it and have fixed it (I think). But I'm making some other updates to the Date Inputfield so going to be committing them all together.

Seddass, are you running the latest PW? Some fixes were put in a couple weeks ago, and those fixes may resolve the issue you are running into. Let me know if you are already running the latest or if they don't resolve it, and I'll get back to work on it.

When you enable the URL segments option for a given template (Templates > Edit Template > URLs > URL Segments) then PW will accept non-existant URLs, so long as they start with one that does exist. So lets say that you have a page called /products/widget/. If URL segments are enabled, then you could access any URL below that and it would be sent to /products/widget/. So accessing /products/widget/photos/ (a page that doesn't exist) would still get sent to /products/widget/. (If URL segments are not enabled, then of course accessing /products/widget/photos/ would generate a 404 instead.) Using the /products/widget/photos/ URL, the 'photos' portion would be considered URL segment 1. You can check the value of URL segment 1 in your template file with $input->urlSegment1. If there were another segment on there too, like, /products/widget/photos/cats/ then 'cats' would be URL segment 2 ($input->urlSegment2), and so on. The advantage of URL segments is that you can have just 1 page handling many URLs. The portion of those URLs that are translated to URL segments are not pages in PW. In fact, if you actually created a page in PW named /products/widget/photos/, then your 'widget' page would no longer receive the 'photos' URL segment, as the new photos page would then have control over it.

This should be reasonably simple to do in PW. I think your best bet is to just grab all the entries you want to display at the top, and then use a counter to keep track of where you are. Written in the browser here, so may need adjustment: $entries = $page->children("sort=-sort"); $images = $page->get("/image_uploads/"); $cnt = 0; do { $cnt++; $entry = $entries->shift(); if($entry) { // output 1 entry } if($cnt == 3) { while(++$cnt <= 6) { $image = $images->shift(); if($image) { // output 1 image } } $cnt = 0; } } while(count($entries) && count($images));

Isn't TAB supposed to tab to the next field? That's what it does in my browsers at least. Do you have a plugin installed that is taking over that behavior? If not, what browser are you using?

I don't know enough about LiteSpeed to say what issues there might be, so my reply is more general purpose and applicable to other servers like nginx or IIS. If everything appears to be working properly with ProcessWire, then the only remaining concern would be security. ProcessWire's .htaccess file is used to keep prying eyes out of some directories and files. Try to access these things in your web browser: /site/templates/basic-page.php /site/assets/logs/errors.txt /wire/core/Page.php /site/modules/Helloworld.module /wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module You should get either a 403 (Forbidden) or a 404 (Not Found) when you try to access any of these. This is kind of a random sampling of stuff, but should answer the question as to whether LiteSpeed is translating the blocked directories/files properly. If it is not, that would be a real security problem, so we'd need to figure out how to block LiteSpeed from allowing access.

Landitus, try adding this to one of your templates somewhere, view a page using it, and see what it says. Replace '/path/to/parent/' with the path to the parent page of the children that aren't getting the correct sort in the admin. $children = $pages->get('/path/to/parent/')->children(); echo "<ul>"; foreach($children as $child) echo "<li>{$child->sort}: {$child->url}</li>"; echo "</ul>"; What you should see is a list of a child pages with the number on the left starting at 0 and incrementing by one for each. But let me know if you see something different. Another thing to try would be to change your parent to have some specific sort, save it, then change it back to no sort. I can't say as though I've ever had to do that before, but it seems like one way to just reset things there, just in case.

I'm unfortunately not trained in legal matters well enough to know what the distinction is or if it even matters. The GNU license doesn't like copyrights removed, but don't know how specific it is. So I can't give a solid answer one way or another here. I'll make a note to ask this the next time I come across someone that knows about this stuff though. However, outside of this, there are a couple reasons you may not want to remove it: 1) unless you make your own admin theme, you'll have to do the same thing every time you upgrade (which would be a pain); 2) With GNU software, it's required that the client gets the same GNU license, and they should understand it and that it's copyrighted software. You don't want them to think they are paying you for the software itself rather than your services.

Just to confirm, the sort settings in your screenshot are for the parent page of those you are trying to sort? If you can, turn on your developer tools (Firebug in FF or Dev Inspector in Chrome). Watch what it does when you finish the sort. Do you see any JS errors? If you click on the network request, do you see any messages in the response that look like errors?

I think what's missing here is that $newpage doesn't yet have a template assigned, or an ID, so technically there is no images/files path that exists yet. You would need to assign a template to $newpage before it would even have an images field, and then you'd need to save the $newpage before it would create any directories for file storage. $newpage = new Page(); $newpage->template = 'template_with_images_field'; $newpage->parent = '/'; $newpage->title = 'New Page'; $newpage->save(); // now these should work. echo $newpage->images->path; echo $newpage->images->url;

I think what Diogo is saying is that with a URL segment you can take a different path depending on what the URL segment is. For instance: if($input->urlSegment1 == 'photos') { // output photo gallery } else if($input->urlSegment1 == 'rates') { // output rates table } else if($input->urlSegment1) { // unknown URL segment, send a 404 throw new Wire404Exception(); } else { // output default } So you don't need to have a separate page for the segments you are looking for like 'photos' and 'rates' and any others. This can be a worthwhile technique in some instances and it sounds like yours would be one of them.

Just wanted to follow-up to say that there isn't anything built-in that can tell you what the most visited pages are. You could certainly add a hit counter field to a page and increment it, and save on every page view, but I think that would be kind of inefficient. It would also prevent you from using any cache features if you are having to save a page on every view. I think the best bet is to do what these guys suggested, or subscribe to a hit counter service that bundles this info into an RSS feed or JS widget.

Regexp is definitely the easiest way to go here. You could do it with just string functions, but it would be a pain for sure. As for the block syntax, I would suggest that simpler is better. People will use them if they don't have to remember too much, so something like {tag} or even {{tag}} is I think easier to remember than {% tag %}. I'm not sure that I understand -- do you want to hook into a textformatter's format() function, or do you want the textformatter to hook into something else?

Actually it needs to be whatever you've named your comments field, whether 'comments', 'comment' or feedback', etc.

Good points on using the ID. Might require some core changes, which the workaround wouldn't. For the most part, I like the core to be geared at the common needs of all modules, rather than honed in on one. So I think a workaround isn't necessarily a bad thing. But the core does get more invovled in the needs of file-based modules than it does with any other kinds of modules, so there's some grey area here.

No need to use a role for that. I would just use a page reference to relate them, or you could even do it by page name. You'd perform the check in your template code, but you could get exactly what you want that way.

You could certainly take it a level deeper and then just display the links to it if they had access. On the deeper levels, you'd either want to limit view access to the 'investor' role (from the template access settings). Or if the template is being used for public stuff too, then perform the check in your template code like in the examples above. If you are performing your own check, you may want to redirect them to the login page when they don't have access, or say something like "Become an investor to get access", or just: throw Wire404Exception();

This is a beautiful theme. Great update and nice to see it again. Only issue I'm running into is that if there are more than 4 top nav items, the 5th wraps to a second line where it gets cut off. Not sure if the issue is with the original Futura or the update. But it's a fairly minor thing as I think most probably don't have as many admin menu items as I do.

$numApproved = 0; $numPending = 0; $numSpam = 0; foreach($page->comments as $comment) { if($comment->isApproved()) $numApproved++; else if($comment->status == Comment::statusPending) $numPending++; else if($comment->status == Comment::statusSpam) $numSpam++; } echo "<p>$numApproved approved comments.</p>"; echo "<p>$numPending comments awaiting moderation.</p>"; echo "<p>$numSpam spam comments.</p>";

Any class method preceded with 3 underscores is hookable (assuming it extends a PW class like Wire or WireData). So just make your method name ___myFunction() rather than myFunction(). Use just myFunction() (no underscores) when you call it. I don't understand the question? Not easily done since PW include()'s templates rather than eval()'s them. Meaning, PW can't modify the template before executing it. The way it could be done is by using compiled templates where a compiler converts tags in a template file to PHP code and then saves it as a compiled template. PW then includes the compiled template rather than the original. It's something we'll probably eventually support, but it's a little complex. The other option is hooking into Page::render and replacing tags from there. But that's not ideal because you don't really know where those tags came from at that point. They could have come from user input (like a comment). So you lack the ability to filter at this stage. It's a PW class that I made 2 years ago, before PW was even released, and I haven't looked at it since then. I just took a look at it now, and it's not in a state where I think it would be helpful or functional. I'd made it as a proof of concept to revisit when the time came to support EE style loops and open/close tags with embeded markup. But that's all it does... it's not an actual tag engine. It's just notes to myself on how a markup embeeded tag might work. I'll still send it to you if you want it, but realize that: 1) it is not a functional module, and 2) It's been awhile, it's a mess, and inexplicable at the moment.