ryan

Jquestion, one good thing that has changed in ProcessWire since that post you linked to was written is that the user system is now built around pages and templates. You can add whatever fields you want to your 'user' template. This opens up a lot more possibilities that didn't exist back when that post was written. So if you want multiple users to have access to a given page, you might just want to create and add a new page reference field to the 'user' template. You might call it something like "client_page". Use 'PageListSelect' or 'PageListSelectMultiple' as the Input field type for that page field. Now when you edit a user, you can select what private page(s) they should be able to view. In your template used by that private page, you'll want to have some kind of access check in there like this: if($user->isGuest() || $user->client_page->id != $page->id) throw new WirePermissionException("You don't have access to this page"); or if a multi-page reference field: if($user->isGuest() || !$user->client_pages->has($page)) throw new WirePermissionException("You don't have access to this page"); To allow for logins by email address: if($input->post->login_submit && $input->post->email) { $email = $sanitizer->email($input->post->email); $emailUser = $users->get("email=$email"); if($emailUser->id) { $user = $session->login($emailUser->name, $input->post->pass); if($user) { echo "Login success!"; } else { echo "Login failed!"; } } else { echo "Unrecognized email address"; } }

In that case you want to use 'installs' rather than 'requires'. Either that, or don't use dependencies at all and just $this->modules->get('module'); in your install(), which will install it automatically (if it's files are in the /modules/ directory). Use 'requires' for things like other 3rd party modules that the user might have to install separately, or modules that the user might have to configure after installing. The 'requires' option is also useful for preventing un-installation of modules. If one module requires another, then the one required can't be uninstalled so long as the one requiring it is installed.

Nico this looks really nice. Quality code too. I also look forward to checking this one out in more detail. It did get me thinking that you might also be interested in distributing something like this as a site profile. The advantage there is that you can have everything already setup so that someone can install and literally start creating blog entries with everything ready-to-go. Let me know if you are interested in doing this as a site profile too, and I'll be happy to collaborate with you on it.

Welcome to the ProcessWire forums Gilles. I think that PW will work quite well for what you are talking about. While I've not pushed it into the arena of 200k+ pages, I think it should scale nicely. You'll want to create the fields in ProcessWire, and I would suggest using the same names that you already are in your tables. You will create 2 templates: "word" and "quote". I'm assuming that multiple quotes can reference the same id_word. Unless your words or quotes can be categorized into single categories of some sort, you'll want to bucket them into two parents: /quotes/ and /words/. In your "quote" template, id_word and id_quote will be Page reference fields (select type "Page" when creating a new field). I'd suggest using the Autocomplete Inputfield for them, giving the scale. But using the page reference fields is the manner in which you'll be able to draw relationships between words and quotes. Since you'll only be updating the online database rarely, you'll want to use the API to handle your import (I'll be happy to follow-up with code examples if you are interested). I would suggest bootstrapping ProcessWire with a command line PHP script (or create a in import page/template). I don't think you'll be able to use the ImportPagesCSV module for this unless you break it down into smaller CSV files. Importing 200k+ records is likely to prevent you from doing any kind of 1-step import due to memory limitations. But when you use the API, you can wire('pages')->uncacheAll(); regularly to clear out pages in memory to make room for more, and this is a good thing to know about whenever doing any kind of large import from the API. But PHP is not MySQL or Access, and you may still find yourself having to limit the import to a few thousand items at a time, depending on how PHP is configured. Keep us up to date how it goes with this, it sounds like quite an interesting scale and application. Thanks, Ryan

I've always been able to upload files. There must not be a limit for administrator. I just hunted around in the IPB settings and found where the limit was. I removed all limits, so hoping this does the trick. Can you guys try to upload something? I think this is what we should do. I'll have ProcessWire check for existence of a content.css somewhere like /site/modules/InputfieldTinyMCE/ (or /site/templates/styles/?). If it finds it, it'll use it instead. Are you interested in doing this through a pull request on GitHub (into PW 2.2 source), or do you think better to copy/paste from the files you linked? In this context, I mean "core module" rather than "/wire/core/" ... something that gets included in the distribution. TinyMCE has a lot to do with the CMS side of PW even if it's technically a module. I see good core modules as any that are applicable to lots of installations (like at least 30% of installs). TinyMCE fits this, and I'm guessing it's used in at least 90% of installations.

Diogo, ProcessWire 1.x actually used MarkItUp and it's a great editor. I definitely want to get it going again in 2.x, hopefully soon unless someone beats me to it.

Soma this looks really interesting. I'm wondering if we should be including the CSS extras plugin and modifications you've made into the core TinyMCE. Can you think of any down sides? Sorry you can't upload files. I'm not sure why, I need to check with Pete on this.

This is because we don't necessarily know the needs and programming level of the audience, so always try to present stuff in the most basic way possible. You already know your way around PHP, so some examples will seem simplistic. But my hope is that as people learn more, they uncover more layers and ways of doing things. For instance, the basic site profile uses a simple header/footer include system for the main markup, and each template outputs what's in between. This isn't the way I usually build sites. But I learned early on that the way I build sites doesn't connect with people until they know their way around the software. So the header/footer system is a way to relate back to the methods used by more entry-level systems like WordPress and Expression Engine. I'm also hopeful that we'll get more site profiles available for download that get into more advanced techniques that'll be better examples for the PHP coders in our audience. CMS architecture is one of my favorite topics, and I hope I didn't suggest you were being negative--you always ask good questions and I enjoy the discussion. What WillyC was referring to above is how you can bootstrap ProcessWire from another PHP application or command line script. If I understand what you are talking about correctly, this may be in line with what you want to do because you could create your own index.php and include() ProcessWire's index.php. From that point forward, you have a wire('api var') function that gives you access to the entire PW API, leaving you in control of everything else. Here's another really basic example: if you wanted to grab your /sitemap/ page and render it: test.php: <?php include("/path/to/processwire/index.php"); $page = wire('pages')->get('/sitemap/'); echo $page->render();

Thanks for reporting back, glad that it's working. I was stuck trying to determine how it was doing that, so it's a relief to hear it's resolved. This has still been valuable though as we did solve a bug as a result (top of this page).

Just playing with it, even now I get strange behavior. Could be something related to cache settings in MAMP's apache, but who knows. TinyMCE is pretty fantastic for what it does. But it's also one of those things I've always had to look past and just go with the flow sometimes. I've lost entire days to little issues in TinyMCE only to find them disappear on their own the next day.

I'm not sure this describes what it actually does, or I might be misunderstanding what you are trying to say. But what actually happens is that the template file assigned to the accessed page gets executed, as a PHP file. ProcessWire spits out no content. You have to specifically code your template file to spit out content. ProcessWire does not participate in this aspect, only you do. That template file is handed a copy of $page, which represents the page that was requested by the URL. Whether you choose to do anything with that $page is up to you. This is an architecture that ProcessWire supports. Make all your pages use the same template file and this is what you will have. This doesn't mean all your pages have to use the same 'template' (unless you want them to), just the same 'template file'. To achieve that, edit each template, click 'Advanced' and set the 'Alternate Template Filename' to be the one you want to be the top of your pyramid (i.e. main.php). Another way to do it is to maintain separate template files that just include("./main.php")). Either way, all valid requests will be routed to your main.php with $page being the only thing different from request to request. If you want requests routed to your template file that don't map to URLs in ProcessWire, then edit the template settings and turn on URL Segments in the URLs tab. Now all URLs below the page(s) using that template file will be handed any URLs below them that don't map to pages. You can then map $input->urlSegment(n) to whatever you want, whether a function/class method, another $pages->get/find call, another application, etc. This is a lot of fun to be had in here. You can do this, but your htaccess will have to identify the paths that get directed to your own script by looking for them with a rewrite rule. Or you'd have to put your script in a directory that is the same as the URL used to access it (or at least, the first url segment is the same). The htaccess file does not know which requests will result in 404s. It doesn't know what is "non-cms" unless the request is to a real file or directory. ProcessWire is what ultimately generates the 404.

I've been down this road before with the theme_advanced_styles / content.css and have had strange and inconsistent behavior. However, that was with the previous version of TinyMCE. I've not tried it since we've upgraded. If your experience is any indication, this all works now, so that is good news! I will plan to get a core entry added for theme_advanced_styles.

If you can figure out how to make it work in a portable way, we'll make it part of the core. Please let me know what you find. Those classes are intended for built-in image alignment functions. They aren't intended for the styleselect. I'm just not (yet) sure how to prevent them from showing up in the styleselect. Are you also seeing the random jQuery UI style in there? I'm in the dark about that one...

That's because the defaults get overwritten by the field-specific settings. Those defaults only serve as the default settings at the time the field is created. If you want to change them for an existing field, you'll need to go edit the field in the admin. Setup > Fields > [your field] > Input (tab) > TinyMCE Advanced Settings. The purpose of this is so that you can have multiple TinyMCE fields without them having to all share the same configuration. It's actually the opposite. The hard-coded setting you tried to change was being overridden by the dynamic one. I think this seems like a good idea to provide the option for this. But I don't want to send people towards modifying it until I can get a predictable behavior out of content.css. Right now, if I add stuff in there, sometimes it works and sometimes it doesn't. Likewise, some styles showing up (like the jQuery UI one) that aren't in my content.css. I need to spend some time in the TinyMCE forums I think.

Diogo, I made a little correction above because the "categories=$thisCategory" would not work. You actually need to pass the $page object into the string rather than the title. Alex, if you want to get everything up and running quickly, and then go back and tweak the markup later, you can also go to Modules > Markup > Page Array Markup > Install. That adds a render() method to PageArrays, so that it'll output some basic list markup for you. Then you can do this: Category: <?php echo $page->categories->render(); ?> For your category template that lists all entries in a given category, you can do this: <?php echo $pages->find("categories=$page")->render(); ?> As things grow, you may want to add pagination: http://processwire.c...rkup-pager-nav/ Then you can do this: <?php echo $pages->find("categories=$page, limit=10")->render(); ?> ...and it'll paginate the results by 10 items per page. Unless the output of the render() functions is provided what you would want anyway, it's better to go back and replace them with your own foreach() statements to iterate the pages like in Diogo's example. But i sometimes like to use these shortcuts to get the functionality down quickly.

I don't know of anything non-standard about our implementation with this, but if you can think of any ways to change it for the better I'll be happy to. Tell me what you've had to modify/hack to make it work and we should be able to make it a core change. I've never had the styleselect working the way I want, and it's in part because it seems like TinyMCE requires changes in multiple places for this, including its content.css file, so just didn't seem particularly straightforward from a simple-configuration standpoint. So the intention with PW's TinyMCE was to just exclude the styleselect, since I didn't want my clients using it, nor was I sure how to explain it to anyone else. Looking in the code, I can see one reason why it's not working. There should be a comma after "styleselect" and before the "|", i.e. "styleselect,|". So if you edit the setting in Setup > Fields > [your field] > Input > TinyMCE Advanced, you should be able to correct it there. Styleselect wasn't intended to be included in our default TinyMCE settings anyway, so that must be a bug I introduced in 2.2 when experimenting with the styleselect. Luckly, TinyMCE appears to just ignore it, so not much of a problem, but I will correct it in the next commit. Assuming you can get the styleselect working as easily as I did here (by adding the comma in the field settings in the admin), then next question comes to what styles it should show. This is where I get hung up. It's pulling them from content.css, but this is something that one must edit to add more styles to it, so not as portable as I'd like... I'm also not sure why a jQuery UI style is showing up in there. When it gets down to it, I just don't understand the TinyMCE styleselect and how to get it to pick up exactly what I want (and none of what I don't), despite repeated attempts at trying (and I did read the docs).

Great site Marty--Fantastic work!

ProcessWire is very different from something like WordPress, where one would browse and install pre-made site themes. There aren't pre-made sites to go (other than the default profile, at present). This is because the audience is one that wouldn't typically use them anyway. Our emphasis veers more towards designer/developer tool, where the needs of the individual site tell the CMS where to go and what to do, rather than the CMS telling the site what to do. This is the opposite of something like WordPress. Though the line can be difficult to envision because ProcessWire can do everything WordPress can do, but WordPress can't do the things ProcessWire can. Think of ProcessWire as a tool more like jQuery, where it's there to help you build what you want, rather than build it for you. Though I don't want to suggest that ProcessWire is limited to that. But that is what separates ProcessWire from other systems. In the future, I'm sure we'll get into providing ready-to-go sites and themes too (it's easily possible now), but we're most geared towards supporting the professional designer/developer community now. I still think WordPress is the best tool if you want to pick out a theme, and put up a site without developing it. But we will broaden in to this area as we grow too.

This is my mistake, I sent in you in the wrong direction with regard to $user before. (Sorry about that) $user is actually still the one that was originally supplied to the template (guest). So you need to use the $user returned by the login function. Change your login line to be this: $user = $session->login($input->post->user, $input->post->pass); if($user) { // login success if($user->isSuperuser()) { // now this should work } } The only reason this is necessary is because $user was supplied to the template before the login occurred, so that user is still 'guest' unless you change it (like above).

Looks like a great solution, thanks for posting Diogo. A couple of suggestions I'd have would be: 1. For all your $pages->get("title=$email"), I'd suggest making them as specific as possible since they can be initiated by a user. Specifically, I'd make it "title=$email, template=person, parent=/subscribers/". While not technically necessary, it just puts in another layer of security at very little expense. Who knows, maybe you'll use email addresses for titles somewhere else? 2. You may want to consider changing your $page->delete() to a $pages->trash($page), just to give you the opportunity to review who unsubscribed before emptying.

Definitely sounds like a great idea and I agree about the value of it. If you decide to pursue such a projectm let me know how I can be of help.

Count me in to help anywhere needed too. I don't consider myself an ecommerce expert, so not really sure on best approach with a lot of things, and don't think I'd be the right one to lead such an effort. When you get into supporting multiple gateways, shipping methods, currencies and such it becomes quite a complex thing. As a result, I've always delegated ecommerce to other software. Currently I run Drupal UberCart and Shopify. I've also run OSCommerce in years past (what a mess that is). The thought of having a PW-based solution is attractive.

That's correct that the method currently in the core does require it's own site directory and database, though shares the same PW installation and web account/web root. It's an entirely different method than what we're talking about here. But I've just been trying to mention it as a side note in any related discussion (not always sure who's looking for what). The code outlined in this topic is more of an untested theory. Though I don't see any reason why it shouldn't work. I would eventually like to have a core method for running sites on the same DB too.

Thanks for reporting back. Glad to hear it's working how it should.

PW 2.2 uses a newer version of TinyMCE than PW 2.1, so there have definitely been changes in this area. But I've not seen this behavior with line breaks. Are there any specific steps I'd need to take to duplicate? I've tried making several edits here but am still getting the expected <p> tags. The only way I can get a <br /> is if I use shift-enter.