ryan

Nice work Radek! Looks like you are putting the new admin theme to good use too.

Sorry I really don't understand the question. But if you needed to sanitize one part and not another, I'd think you'd have to extract it before sanitizing it? You might also want to look into the HTML Purifier options as they do provide a lot of ways you can modify its behavior. For instance, you might be able to configure it to ignore some tags and not others, etc.

Something already sent some output before the header() call. View the source and be on the lookout for a PHP error message or notice at the very top of the output. It's even possible it may be some whitespace by a module that ends with ?> and a space (this is one reason why it's not good to end your PHP files with ?>). When you view the source, do a "select all" so that you can identify if any whitespace is present. This will prevent a header() call from being successful.

This module assumes that you have entity encoding turned on for your title field. (See Setup > Fields > title > details > Text formatters). This is something you should always have enabled when using ProcessWire for any kind of HTML-driven output. Changing the quote style in the JS would not be an alternative to entity encoding, because you'd run into the same exact problem if one of the page titles happened to have quotes in it. Though you could use something like Markdown or Textile too, but I'm honestly not sure if those entity encode apostrophes or not. If not, the only solution may be an str_replace(array("'", '"'), array('"', '&apos'), $page->title); ahead of time. This module can accept a single Page or a PageArray. If given a PageArray it'll map them all and fit the map to the markers. If given a single page, it should still map the marker and use the zoom setting from that marker. However, you may need to modify the module to suit your needs. In the instances where I'm using it, I typically modify it. Though the skyscrapers profile was made long before this module, so it is using something quite a bit older and not a module at all.

That's a good point. Actually what probably would be better here is an argument that lets you specify the max length. 500 is probably inappropriately long for many instances where you would use selectorValue, especially since this function's max length of 100 is referring to number of characters, not number of bytes. I'll go ahead and add that.

The way that ProcessWire does it is to take a path, explode it to an array with "/" as the delimiter and then construct a query that joins back the pages table for every segment of the path. The longer the path, the more joins, and I suppose the more potential for overhead. It sounds potentially slow, but I've found it's actually incredibly fast. While it's nice to have those paths cached in their own table as the PagePaths module does, I haven't seen it make a measurable difference from the uncached/joined version that ProcessWire uses by default. Though if you were having to deal with large numbers of such paths in a single request, it might make a measurable difference there. There's also a lot of potential overhead with renaming or moving a lower-level page with lots of descendants, as it requires re-building the cache for all of those pages. This is the primary reason PW does it dynamically with joins rather than keeping a cache of them like in the PagePaths module. You don't query MySQL directly. I suppose you could query the pages_paths table directly if you wanted to, but that's not the point of this module. An example of a real life query would be to find all pages that have "chicken/nuggets" as part of the URL: $pages->find("path%=chicken/nuggets");

If you are populating this data to a PW textarea field, then it's going to take care of ensuring the data is sanitized for storage in the DB. You don't need to do that. However, what you need to be concerned about is outputting that data. That data could contain stuff that may be perfectly safe for DB storage, but is full of XSS when presented to the user. If you need to allow markup from untrusted users, your best bet is to sanitize with HTML Purifier. We also have a MarkupHTMLPurifier module for ProcessWire. You would simply run it through HTML Purifier before populating to the PW page field, and that would have the effect of removing markup which could be considered problematic or insecure. Another alternative is to use a restricted LML, like Textile Restricted or BBCode. But of course your users would have to use that LML rather than HTML, which may or may not be desirable.

I like Dragan's approach if you don't mind mixing JS into the CMS side of things. Whether that's a good practice or not really depends on who's going to be using the admin. If you want to keep this on the development side rather than the content side, one approach I've used is to keep JS files named with the ID of the page. When a JS file existed that matched the ID of the page, it would be included in the <head> section. Example: <?php $file = "scripts/$page->id.js"; if(is_file($config->paths->templates . $file)) { echo "<script src='{$config->urls->templates}$file'></script>"; } More often, I use this approach with the template file, i.e. have a file named basic-page.js that gets included on any pages using the basic-page template.

Looks like a good one SteveB! I look forward to it.

Looks fine to me MarcC. My process here is pretty much identical to Horst's. Over the next couple weeks, I have to import 3000+ pages each with 10-50 photos. When doing large quantities, you may need to paginate it, or run it multiple times, if you run into any memory issues. Check if the page you are creating already exists and skip it if it does. Something you may also need at the top of your PHP file is: ini_set('max_execution_time', 60 * 60); // give it an hour.

If it requires ProcessLanguageSupport, wouldn't you want it to be "requires" => "ProcessLanguageSupport" ?

The new inputfields.js from the dev branch will attempt to maximize the row with the columns that are in it. If the total does not add up to 100%, it will expand the last visible column to fill the row. I'm guessing this is what you are seeing? This behaves well with the default admin themes (both old and new), but I've not tried Futura Remixed yet. It's possible that theme may need an update if it's not something we can work around. Dependencies are the field names are they are in the markup (id attributes). While I've not tried it, you may be able to get it to work just by using the parent field as it's named in the markup, which is "parent_id". However, you could only match the ID (number), you couldn't match something like parent_id.template=home.

In order to store a file, you need to associate it with a page. Each page has a dedicated location where it can store files. In your case, it may be better to accomplish the functionality you are after with a template (and a page using that template) rather than a module. Though if you wanted it to be a module, you could always create it as a Process module that can handle uploaded files. The ImportPagesCSV module is an example of that. But I honestly think the simplest path is to use a template.

The admin is intended for administrators or site editors, so it's not a place to send general users to. It sounds like you might be having these users modify a profile page? This is stuff you can easily code using the PW API on the front-end, and that's the recommended way to do it. There are some examples here in the forum, but let me know if you can't find them and I can track down some examples.

I think this particular one might be fixed on the dev branch, as I recall hitting the same issue a couple months ago. But the intention is that you shouldn't ever have to use trackChange() yourself unless you are writing a module or doing something out of the ordinary.

2.4 is not PHP name-spaced. I got started with it and realized it was going to create headaches for many web developers having to namespace all their template files (not to mention modules). This is extra baggage that most of our audience would not appreciate. So I've put it off to one of the next versions when I can find a way to do it that doesn't require gratuitous verbosity to people's template files. I think that's possible with a built-in template compiler, but that's a bit more work than I was looking to get into for 2.4. If for some reason that doesn't work out, then we'll pen the namespace change to PW 3.0 when a major version would be more amenable to an upgrade that may require changes to one's template files.

What version of PW? What happens if you change 'booked=0' to 'booked=' or 'booked=""' ?

It seems like we should be able to change that behavior but I can't initially figure out why it's not accepting your argument to the render() method. Just to be clear, $slider is an individual Page (rather RepeaterPage) and not a PageArray? And the render() method is intended to be Page::render? One possible factor may be that repeater pages have their own class: RepeaterPage rather than Page, and this might be interfering somewhere along the line, but not yet deep enough in the code to see where.

I also would like to make it more configurable, and definitely plan to. But in the short term, I think the best bet is just have it not show if there aren't any add-ready templates to populate it with. I will do this before 2.4 is final, but just wanted to keep it there with a little instruction notice to introduce it, as I thought people might not realize the option was there otherwise. Thanks for the screenshot comparison. It looks like the "e" also has the same issue with the bold Open Sans, though to a lesser extent. I notice the 12px size seems to look fine with both by comparison. Is the problem just the 14px font size with these fonts in Windows? Would using a different size (bigger or smaller) as a default be better in the Windows environment?

Without that setting, pages like Home and Trash would retain those labels unless the the LanguageSupportFields module is installed. Since this is an optional module, I figured the system pages should still be translatable via a language pack.

What's on line 71 of that file? Was the PHP version downgraded in the transition? Make sure you are running PHP 5.3.8 or newer on the new server. The table for the field may exist, but does it have an entry in the "fields" table? That error message would suggest it doesn't. I am guessing the database didn't successfully import to its new location. I would try to re-import the whole thing.

I'll try to get this one in later today. This is actually the intended behavior because names specified in each language may not be unique. For example the spelling of Chocolate is the same between English and Spanish. But there are many examples, and it's very common to have the same page names across languages. As a result, "name" in a selector refers to the actual page's name, and not it's name in another language. While names aren't unique for the same page across languages, paths are unique (otherwise PW has no way to determine the language) so that's why your retrieval of the path worked but the name didn't. This is one that we can feasibly get working without too much trouble, if there's a need for it. One way you could do it is to change your "name" selector to a path selector: $p = $pages->find($page->parent->path . "namefor_german");

I don't know enough about the Facebook API to know what's wrong here. But I would guess the Facebook authentication is failing and that you need to retrieve an error code or error message from it in order to know why. Does it have some kind of getError() method that you can call? Also your try/catch block is pointless here, as there's nothing with your try/catch block that can throw an exception. But I'm guessing that's just there as a placeholder that you'll be populating later?

ProcessWire's permissions system is designed to deal with groups of pages (by template). When you get into wanting to assign permission for a specific individual page, the best way is to use your own code to identify the page. An example would be a hook in /site/templates/admin.php wire()->addHook('Page::editable', function($event) { if($event->return) return; $page = $event->object; $user = wire('user'); // if page ID is 123 and user is "joe" allow edit access if($page->id == 123 && $user->name == 'joe') $event->return = true; });

Not currently with this module. Though you could write a quick file to do it for you. Place the following in your web root where ProcessWire's index.php file is, perhaps in a file called fix-names.php. Then load it in your browser. <?php include("./index.php"); // bootstrap PW $items = wire("pages")->find("template=your-template"); foreach($items as $item) { $name = preg_replace('/-s(-|$)/', '', $item->name); if($name != $item->name) { echo "<p>Changing $item->name to $name</p>"; $item->name = $name; // $item->save(); } } Uncomment that $item->save(); after you run it the first time to make sure it's doing what you want. I wrote the above here in the forum and haven't tested, so it may need tweaks.