ryan

Achabany, I'm getting the same thing as Nikola. Chrome 16. (those Chrome version numbers just keep climbing!). Also noticed an issue that can affect some sites but not others. See the attached screenshot. If you add any items to your admin nav, then they can get overlapped with the user/profile/logout links. Some modules add items to the top nav like this. It might be safer to locate that user/profile/logout line above the search... or if you like it where it is and want to get fancy, you could always locate it above the search when $pages->get($config->adminRootPageID)->numChildren > 4. One other minor thing to note in the screenshot is that there's no padding to the right of the title input (and any other full length 1-line text input). Though that's a minor point that doesn't affect use at all, and I didn't even notice it till after I took the screenshot. Nice to see it's multi-language ready too. Speaking of which, since you worked the topnav.inc into your default.php, you don't need to "translate from the context of default.php", since this is assumed: $title = __($title, dirname(__FILE__) . '/default.php'); // translate from context of default.php The above line isn't hurting anything, but it's also not necessary. You can just do this: $title = __($title); …or this (which is slightly faster, but not as pretty): $title = __($title, __FILE__); Thanks again for your great work with this theme.

Great admin theme Achabany! I only have a minute on the computer so couldn't try it much, but got a quick look and love what you are doing with the PageList. I look forward to using this more tomorrow. Thanks for your nice work!

This is working in 2.2. I just had to do it yesterday. I was going to say "what password are you using", but that's probably not a good idea. Instead, why don't you try with another password. There is a known issue in the queue with passwords that are exclusively non-ascii. If you find it's still not working, give me an example of a fictional password that I can use to reproduce the issue.

Oliver, there might be some bug in the version of MySQL there. But I would suggest exporting the whole database with PhpMyAdmin to an SQL dump, then create a new database, and import the dump. Then switch your site to use the new database (by editing the bottom of /site/config.php). Just in case there's a problem specific to that DB, that would at least put it in a fresh state. Please let me know if you find anything else.

Nice module Nico! I have a few suggestions: 1. The current way you are using $pages->find() to find files is going to mess up the pagination for any pages that have blank file fields. For instance, on the site I tested, I have 30 files, but hundreds of pages with blank file fields. I ended up with 90+ pagination links, where most pages were just blank. So I think that finding files by template is probably not ideal. Instead I'd suggest finding them by field. This will work: $fields = $this->fields->find('type=FieldtypeFile|FieldtypeImage')->getArray(); $pages = $this->pages->find(implode('|', $fields) . ">0, sort=-modified, limit=10"); 2. You have some stray var_dump() functions that are breaking the display in some parts of the module. 3. In your executeDelete(), I don't understand why you have this line: foreach($f->page->getInputfields() as $field) { It doesn't seem necessary? I would get rid of it if you can.

I didn't know about this. Sounds useful and I like the sound of it, but haven't seen it. Yet another thing I need to investigate further. I think we'll just go one step at a time here and start with implementing your improvements. It'll be a few days here before I can make these updates in the core, but I think it'll be a good thing to do. The only plugins PW has into TinyMCE are the pwimage and pwlink plugins (images and links). These are powered by ProcessWire rather than TinyMCE (for the most part). What sort of extensions or improvements would you recommend?

It shouldn't matter if you've renamed the admin page, but thanks for mentioning it. Those are the kind of things that are good to know. Let me know if you find that you can reproduce it. Thanks, Ryan

Here's how: So you basically create the blog site, then run that profile export. Then take the /site-default/ directory from a blank ProcessWire (one where the installer hasn't yet been run) and replace these directories in it with the ones from your blog site: /site/templates/ /site/modules/ /site/install/ Then zip up that entire /site-default/ directory, or put it on GitHub. This is a site profile. Now anyone can replace the /site-default/ directory in a new copy of ProcessWire with yours, and it'll install your blog site. I also often use this technique for migrating client sites from dev to live.

Testing here in 2.2, but I can't duplicate. Can you think of any other factors involved? Has your site been through a profile export/import (like 2.0-2.1 upgrade)? Have any admin-related pages been renamed? Let me know if you can think of anything else that might be different from a stock installation. Tahnks, Ryan

I agree with all your points, it's a great framework. Admittedly it's rare that I use a traditional framework as most of the work I do better fits in line with what ProcessWire does. But if I found myself in a project that called for a more traditional framework, Symfony2 would be one of the first I'd consider. I've not considered this need before, but you should be able to add a snippet to the top of your /site/templates/admin.php that prevents it from being accessed by your main site: if($config->httpHost != 'admin.mysite.com') throw new Wire404Exception(); As for making the admin run at the root path, I don't immediately know of a way to do that while still having it power a site. Though you can certainly rename the admin page to something more transparent like "a" rather than "processwire".

That does seem very strange. I'm impressed you went to the effort of trying out the query independently. If the query is failing (not updating) even when trying it directly in a MySQL client (like PhpMyAdmin) then it seems like there is a MySQL error or bug occurring here? Can you confirm that following up with this query shows the non-updated value? If it's showing the incorrect value, you might want to try to run a database repair on the table (in PhpMyAdmin, check the box next to the table and select 'Repair' from the select box). If it is showing the correct value from PhpMyAdmin, then let me know as we'll need to look at some other things.

Why can't you login into PW with Firefox 9? (FF9 is my native browser). Just curious if I've missed something?

Can you expand on this? I'm not sure I understand what you mean. If we can make it possible for everything in TinyMCE to be customizable outside of the core, then I'm all for it. The problem is, I don't yet have enough expertise with TinyMCE's architecture to know how. We need a TinyMCE expert on our team to help maintain and optimize this module--interested in the job?

This is a good thing to do with your own sites, but not a good thing for ProcessWire to do since we can't safely assuming PW is "online". PW is used in some offline contexts. I develop offline too. What Antti said is correct. I recommend including your own jQuery scripts for your site. While you certainly can use PW's jQuery modules, it's best to keep the needs of your site independent from the needs of the admin (to prevent a PW upgrade from breaking something in your site's javascript, for example). jQuery stuff isn't always backwards compatible. I originally used 1.2.6 rather than the newer one, because the newer one was buggy, and having issues with new versions of jQuery. This may have changed in the last year (hopefully anyway). If anyone has a moment to check it out and test, I'll be happy to upgrade it. Otherwise I'll take care of it as soon as there's time to properly test on this end.

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.