ryan

For the file download, you can also look at the wireSendFile function. It sounds like you found the DB export functions from the profile exporter. For the importer, have a look at ProcessWire's install.php file that can do an import via mysqli or an import via PDO but note that it doesn't work with just any SQL file, as it requires the simple SQL dump produced by the profile exporter (i.e. single line statements and single record INSERTs).

I agree that it does sound like unnecessary duplication. What's the benefit of creating your own users as pages separate from ProcessWire users? I'm not sure I understand the considerations there yet. But if you want to go that route and create your own pages as users, then there's probably no reason to maintain a 1-to-1 mapping with PW users. Instead, you can probably have a single user that you map all your own user pages to. Or perhaps a few separate PW users that you can map to, each with different levels of permissions... but then this is treating PW users as roles or groups, circumventing a system that's already there. I think the question of what users are may be the wrong question and instead it might be better to look at using the existing users system and what management additions are needed in your case. Perhaps modifying or extending the current ProcessUser module to provide the capabilities you need would be the simplest route.

Just want to mention that the module in question is filed under the proof-of-concept category, which means: Maybe there is some question as to whether we should even have this category, especially as the modules directory grows. I would also like to have dedicated modules managers (people) to ensure the quality and ongoing compatibility of modules in the directory. The current scale is beyond my own ability to keep up with on my own, but a team of us could do it. Soma, you would be my first choice, especially given the number of modules you've created–especially the highly-relevant Modules Manager. The current ratings system in there is meant to be a bit of a crowd-sourced solution, where the best modules also have the most "recommendations". But having a bigger QA team would be far preferable as a primary solution.

It's not necessary here, as ProcessWire doesn't include the http host with url() calls... just the path. So you can prepend the http host yourself, or make a custom function to do it for you. For example, you make an uppercase "URL" property to refer to your own version: wire()->addHookProperty('Pagefile::URL', function($event) { $event->return = "http://www.domain.com" . $event->object->url; }); Usage: <img src="<?=$page->image->URL?>">

It probably is possible. It's going to use whatever database is defined in your /site/config.php or /site-[n]/config.php file, so that's pretty much all there is in terms of defining what database is going to be used.

It looks fine to me. I would just add a check that the $img exists, before outputting it in your $portfolioGrid variable, i.e. if(!$img) continue;

Most likely something with mod_security. Try creating a template that has nothing but a 'title' field, then create a page using that template and save. I'm guessing that'll work, because the POST has no HTML in it. Some hosts using mod_security just aren't friendly with rich text editors, especially multiple instances on the same submission. You'll want to ask your host how to disable mod_security.

No problem, here it is

The code looks fine to me. I would double check that you've got all the right field names in your code, typos, etc.

Sorry, I thought we were talking page fields here. If limited to the fields in template/field (or module) settings, then I know what the issue is. It's the encode/decode process, which attempts to detect and enforce numeric types and empty values. Best way to bypass that is to put something non-numeric in there. For instance, for a color value something like #000 rather than 000 would likely resolve it. Though I may also be able to have it skip over digit strings that start with a zero and have no decimal.

I'm not seeing this behavior with Text/Textarea fields. Just tried in a few spots. Any other factors you can think of?

It would be a security risk, which is why ProcessPageSearch only works from the admin side. However, if you grab the ServicePages module, that essentially gives you a safety net/mediator between ProcessPageSearch and your front-end.

Just in case anyone was wondering why I've been silent for the last week, it's because I've been away on vacation, so have a lot of catch up to do here (didn't have internet access while I was gone). Just got back last night, and it seems my hands have to re-learn how to type. When I click on "view new content" I have 9 paginations of unread messages–ouch. This is probably going to take me a week to get through, especially with the Christmas holiday here. But I've been anxious to get back into the swing of things here and looking forward to getting focused on PW 2.4 now. Because I'm behind on the messages here, if there is anything urgent that you know of waiting on me, please reply or PM me and I'll make sure to get those right away. Thanks to all of you for taking good care of the forum while I was gone. Also Merry Christmas / Happy Holidays to everyone.

This thread is for the new PW admin theme being developed for 2.4. Zahari and WillyC, I'm sure you guys both have good intentions, but this is not the right thread to promote other admin themes and such. We're now focused on wrapping up and fixing bugs in the new theme, not redesigning it. This is in preparation for the very soon upcoming 2.4 release. Zahari–please do keep up the good work on your theme, post to the directory, and start a thread for it, as I'm sure many of us will enjoy using it too. WillyC–please don't let that one go beyond the sketch stage. I hope you can appreciate that there's no way one could ever get everyone to have the same viewpoint on subjective things, so that is kind of pointless. The goals here have always been more about the system. Then taking that system and reducing it to the most minimal, easy-to-use implementation. All while still incrementally improving on the old theme. The consensus has been that's what we've done, even if we're still working out some bugs. We'll let others take it and run with it in creating stuff more tailored towards their own preferences and other scenarios. The biggest complaints with the old admin theme were: 1) the colors don't have broad appeal; 2) the header area used entirely too much space; 3) the fields layout was too boxes-in-boxes with excessive linework, emphasizing the containers over the inputs; 4) the type was too small. The consensus and the math has been that the new admin theme solves these issues, while appealing to a broader audience than the old theme. Keep in mind there's no way to make everyone happy, so it's entirely expected to have a hater or two (I'd be more concerned if there weren't). Also keep in mind the old admin theme has a consensus of haters, among those that don't use it every day. So it's a bottleneck when it comes to new users. Is the new theme meant to be some kind of design masterpiece? Absolutely not–it is intentionally trying to avoid making design statements, and focused on reduction to essentials (though not to the point of looking like Craigslist). When it comes to the bigger design project (PW 3.0), we'll hand this off to Felix and Phillip (and perhaps others), who have already nailed the concept. That's my opinion, but we'll seek the input of the community to decide. My experience has been that small team design=good results, community/committee design=bad results. But that's another conversation. We'll move onto talking more about that once we've got 2.4 final. Regarding the Inputfield containers: yes there are still situations where the boxes-in-boxes (emphasizing the containers over the inputs) might suit an individual installation or preference better. But there are more where it doesn't. As a result, it's not as well suited as a default (and we've already been through this to excess), but it is something we always want to offer as an option. The new admin theme system allows for configurable spacing between the Inputfield containers via a setting provided to the InputfieldWrapper. We may even make it configurable within the default admin theme at some point, but I'd rather see other themes focus on things like that. As for the typeface: Arimo vs. Arial. I agree with most with the points about Arial, and I think the arguments presented here against using any webfont make sense. As much as I like Arimo and as good as it looks on my own computer, I think we've got to revert to Arial–it makes more sense with this theme's goals and in the big picture.

Also, make your "text", "date", "city" and "podcast" fields autojoin in your advanced field settings like WillyC mentioned. That should cut out a few hundred more queries as well. To avoid the nested loop, just keep track of when you need to output your headline. You want your data grouped by tour, so you'd sort by something from the parent, followed by the concert date. Perhaps "sort=parent_id, sort=date" in the concert finding query. Then keep a $lastParentID variable that you set at the end of your loop ($lastParentID = $concert->parent_id. At the beginning of your loop, check if $lastParentID != $concert->parent_id and display a headline when the condition matches.

There must be a lot of photos in there for the counting of that field to be a bottleneck? Something that may be even faster is to load the concerts that have photos in one query and label them as such, then load the concerts that have no photos in another: $concerts = $pages->find("..., fotos.count>0"); foreach($conerts as $concert) $concert->has_photos = true; $concerts->add($pages->find("..., fotos.count=0"))->sort("title"); Using that method, output code would just check $concert->has_photos; rather than count($concert->fotos); But you will have reduced 250+ additional queries down to 2.

Yes, every single repeater field has an associated template. Repeaters aren't designed to be used in this way (selecting repeaters from one page on another page), this is really more a use case for regular pages sans repeaters. Though I'm guessing that technically you could still do it if you needed to by creating a Page reference field that selects your repeater template with a custom selector like this defined in the field settings "template=repeater_something, check_access=0, sort=title", replacing the "sort=title" with whatever would be the appropriate field to sort on.

I've not seen this particular issue yet, but use CKEditor every day. There must be some combination of factors that causes it, but it's not clear what it is.

It looks like you are using http_build_query to build a query for $pages->find(). That's something you'd use to insert a query string in a URL, but it's not something you want to use for a selector. Instead, you'd want to sanitize selector values with $clean = $sanitizer->selectorValue($dirty); Though if you've already sanitized something as an (int) then it's not necessary to run it through selectorValue. For your 'sort' you'd want to setup a whitelist of valid sorts and validate against that. Rather than doing a "die()", I suggest doing a "return;" so that you pass control back to PW rather than terminating execution. To find only modified products since a particular date, you can include that in your find() query. Perhaps the client can specify "modified" as a variable to the web service. If they specified it as a date string like "yyyy-mm-dd h:m:s" then you can sanitize and convert it to a timestamp with $date = strtotime($str). Then use "modified>=$date" in your selector. To find which pages were deleted, the client usually identifies this by the non-presence of an item that used to be there. I also like to sometimes setup a separate "exists" feed that the client can use to test their IDs against. For instance, the client might query domain.com/path/to/service/?exists=123,456,789 and the response would be handled with something like this. It returns an array of TRUE for each queried page that still exists, and FALSE for pages that no longer exist. if($input->get->exists) { $dirty = explode(',', $input->get->exists); if(count($dirty) > 200) throw new WireException("You may only check up to 200 at once"); $ids = array(); foreach($dirty as $id) { $id = (int) $id; if($id) $ids[$id] = false; // set as not exists (default) } $results = $pages->find("template=product, id=" . implode("|", $ids)); foreach($results as $result) { $ids[$result->id] = true; // set as exists } header("Content-type: application/json"); echo json_encode($ids); }

Sounds like exactly the sort of thing modules are for. I'm always a little wary of overloading the core with too many options, so the primary test is whether something would be used by at least 30% of people. If so, then it may have a place in the core.

Just to follow up here in case anyone else ever runs into something similar: WillyC was correct about the issue here. It just needed to be an HTML HannaCode rather than a javascript one. Also wanted to mention I've posted an update to HannaCode, version 0.1.4 which fixes a couple of bugs having to do with the Ace editor. It fixes the issue where extra whitespace was getting inserted at the end of the code. It also fixes the issue where Ace sometimes wasn't active after doing a 'save & test'.

I think both of these issues are fixed on dev, but please let me know if you are still experiencing either.

Pete tracked it down and I put in a fix. The problem was actually related to the prependTemplateFile / appendTemplateFile options not being properly identified in the cache.

Actually I think all instances of $summary were supposed to be $text. Not sure what I was thinking, must have gotten a phone call in the middle or something.

Nice job Pete!