BitPoet

If you search using ~=, you're performing a fulltext search (aka natural language search) that only looks for words. If you need to be able to search for non-word characters too, you'll have to use %= (LIKE). For fulltext, you'll likely need to clear out any non-word, non-digit, non-whitespace and non-connecting characters, e.g. with '/[^\p{N}\p{L}\p{Pc}\p{Zs}]/u'.

Welcome to the PW world @dg234! Your site reads like the perfect task for ProcessWire. While you don't need to move your data from its external tables, chances are high that you will want to do that and create a page for every hike that holds its data, track(s) and images. PW's template files are (unless you install a template engine module like smarty) just PHP files outputting your HTML, so you have every freedom regular PHP scripts give you. PW also provides you with a PDO wrapper to its database in the $database variable, or you can use the underlying WireDatabasePDO class to access an external database. Or use PHP's native database layers. Or use a third-party ORM layer. Whatever you fancy. You don't have to upload your images one by one. You can either drag and drop a number of files at once in the backend (though POST limits may hit you there depending on the server settings) or FTP them to the server and create a short bootstrap script that adds them to their pages. Since you control the HTML, you can include whatever scripts and styles you want, either generically (in such cases I like to put them into an extra include for the header, like _header.php, to keep them organized) or on a per-template basis. If you have a generic page layout but want to add different includes and styles depending on the template, you can use the (popular) strategy of automatically appending one "master" PHP template that produces the HTML and fill the variables used there (like e.g. $content and $headers variables) in every individual template's file as explained here. PW lets you override that setting on a per-template basis, so, like with most things in PW, you have every freedom. Just keep in mind that PW's pages first and foremost are equivalents for tables to store your data. The fields you assign in the backend template are their columns. Page fields, Repeaters and the implicit parent-child relationship are links between these "tables". Not every page needs to have a PHP template, in that case it can't be viewed directly but still used to hold and render data in other pages, but once you have your data in pages, it's easy to display it as well as search for it using PW's extremely powerful selector API. To wrap it up, you'll be able to do most if not all things you need with PW's default functionality and a handful of already available modules. I don't see a need to develop your own module yet, but there is a getting started documentation for module development in the online docs and, if you find that you do in fact need to, just ask here and you'll find a wonderfully helpful community.

The quote above reminded me of something I tried a while ago: <?php /** * Keep track of module config versions in ProcessWire. * Allows smooth upgrading of module versions when configuration * options change. */ class ModuleConfigVersion extends WireData implements Module { public static function getModuleInfo() { return array( "title" => _("Module Config Verisons"), "summary" => _("Store module version in config to allow smooth upgrading."), "version" => "0.0.1", "autoload" => true, ); } public function init() { $this->addHookBefore("Modules::saveConfig", $this, "hookSaveConfig_SetVersionProperty"); } public function hookSaveConfig_SetVersionProperty(HookEvent $event) { $module = $event->arguments(0); $data = $event->arguments(1); $moduleInfo = $this->modules->getModuleInfo($module); $version = $moduleInfo["version"]; $data["version"] = $version; $event->arguments(1, $data); } } This automatically adds the version each time a module's configuration is saved.

One thing I'd definitely never do is mix values of different languages in one language's field. It's bound to come back and haunt you. To get around template additions/changes, you could simply add a (hidden) field to them. Then, in your hook, simply check $page->template->hasField("yourhiddenfield") instead of comparing template names. Lastly, I'd change your code above a bit to always try the user's language first, then try to fall back to the absender's language and lastly the default. public function hookLangInherit(HookEvent $event){ $mlObj = $event->object; // LanguagesPageFieldValue object $currPage = $this->wire('page'); if($currPage->template->hasField("flag_absendersprache")) { //check if detail page is accessed if($this->input->urlSegment1){ // The overview-content and fetch-content pages are living under a specific rootParent which has assigned a specific "absender" $absender = $currPage->rootParent->choose_sender_2016; // Get The new language by a custom pagefield(single) from the "absender" $sprache = $absender->inheritLanguages; $usprache = $this->user->language; $dsprache = $this->languages->getDefault(); // Take the first non-empty value in order of precedence: // First the current user's, then the absender's, then the default language foreach(array($usrpache, $sprache, $dsprache) as $lang) { $newLangValue = $mlObj->getLanguageValue($lang); if($newLangValue != "") break; } // Get the new values in that language $event->return = $newLangValue; } } }

With UTF8, it's no longer necessary to encode any characters outside those that have special meaning in HTML, so accented chars are fine as they are. If you enable the text formatter "HTML Entitiy Encoder (htmlspecialchars)" in the details tab of a field that contains plain text, it will take care of any necessary encoding on the fly. CKEditor will do its own conversion as you type, so manual conversion shouldn't be necessary anymore.

How about calling $field->setAttribute("cols", 40); ? columnWidth only sizes the Inputfield's wrapper, not the actual HTML input element itself.

Underscores in host names are invalid according to RFC1132, which allows only letters, digits and hyphens. They are only allowed in DNS names for resource records. So PW is operating in undefined territory.

Welcome to the ProcessWire forums then! You've certainly found the right tool for such a task. As to your questions, you're of course right. Under the hood, it all boils down to MySQL statements, so for a reasonably experienced DBA, sanitizing data and optimizing indexes isn't magical. A lot of the terms and descriptions you've encountered are thus meant for frontend developers or those who aren't able to breathe SQL instead of oxygen The "easier and safer" part means that you should PW's API to access PW's pages and fields, not invent your own SQL to do so when there's a perfectly simple API already in place that sanitizes its selectors and builds the correct JOINs, and if you have means like calling $page->children("rank=".$sanitizer->selectorValue($input->get->rank)) or iterating $page->somepagefield you don't have to worry about someone sneaking a POST or GET value past you that lets them view data not meant for them, nor do you have to worry about accidentally removing valid characters, all the while the code is wonderfully descriptive about what it intends to do. I guess you could go with storing most of the relevant data for your game in custom tables, and as long as you're the only one managing the system, you'll be fine. If, however, things keep growing, you either need someone equally versed in databases (especially if something goes wrong unexpectedly), or you need a good visual representation of your data in the backend - that's where pages come in. Since pages are just DB entries in the "pages" table and their fields associated rows in a field_FIELDNAME table, there's not much overhead but a lot of visible gain. In case something unpredictable happens (like a winner being disqualified afterwards) you can simply go into the backend, open the page for the race, edit the "results" field and remove the participant in question. That's a simplified example, of course (you'll likely use something more elaborate than a simple page field, e.g. a PageTable or Repeater so you can also store the time and perhaps starting slot and completed rounds), but the gist holds true. Being able to see your data at first glance and being able to use the backend to modify and reorder it is the main advantage of using Pages and Fields. Think of pages not just as display interfaces in the frontend, but more as links between your data. A page's template is its data model and the page id the key that links the instance data. A pagefield links to another model's instance. You get all that referential stuff with a nice GUI. There are a few more obvious advantages of pages, like their status flags. Set a page to hidden and it's not listed in $pages->find() calls. Set it to unpublished and it doesn't show up at all. Of course page access can be limited in any number of ways, but to use PWs built-in access system, you need to have pages. There are pages for displaying data, which you'll have anyway, and there are pages only for storing data to be associated with other pages but not to be displayed on their own. Again, don't just think of a single admin scenario. With multiple editors/admins (like customary for a larger CMS) you can for example limit just who can modify these data pages - this might be a lot fewer people than those who can update the pages including their values. Avoiding name clashes is always an issue when you import pages. Each page name under the same parent has to be unique - it's used to build the URL to the page, after all, no matter if the page is accessible through the web or not (yet). The logic for page names and the danger of duplicates differ from case to case, so it's always something you'll have to determine yourself how to deal with. Ryan's approach in the linked topic is ProcessWire's default logic, but if a name already exists, you could also let your import script create a completely different name with a microtime-based timestamp with a fixed prefix so you can find those later and deal with them manually, or you could avoid importing them at all and just log a warning, or you could put in your own logic to create a unique name. In case of races if you might e.g. be normally using location-date as the name pattern, but you might have two races on the same day there and append the race number. Whatever fits your need. I'd suggest you play around a little with field templates / partials. Your site might be a perfect use case for those and explain far better than any prose we write here what the real advantage of using pages and fields for any kind of data can be.

Are you running PW 3? In that case, make sure you use the FieldtypePDF module downloaded from the devns branch at github, not the one in the modules repo.

I'm still in the middle of an almost complete rewrite. I still plan to have it finished by Christmas, but I don't dare to give a more precise estimate right now. As soon as that's finished, I'll release it as a beta and do some heavy-load testing in our intranet to confirm its stability.

This should be Paths.php, not Path.php right? It looks like something assigned an array to $config->paths->something. Dumping $key might get you on the right track of which "something" holds the array value PW complains about.

That depends on the exact definition of "most popular". If its just the number of visitors for each post, you could add a visit_counter field to the blog_post template and include the code shown in this post in blog_post.php which increments the counter with each new view per session: Then you could simply run a selector with "template=blog-post, sort=-visitor_counter, limit=x" to show the top x most visited posts. To get it visible: use one of the templates like blog-recent-posts copy it and its PHP file to blog-popular-posts adapt the selector in the PHP file like above create and publish a page "Popular Posts" for the new template and finally add "blog-popular-posts" to the $template array in blog-main.inc (line 16) so it shows up in the navigation (untested!)

Could it be that the page has set a status that prevents deletion like Page::statusSystem? In that case, removing the status flag before deletion should make it work. This can be seen in the "Settings" tab.

I use the Page Edit Soft Lock, which issues a regular AJAX request to keep the lock updated. Unless you have session fingerprinting activated and use the IP address (which IMHO only makes sense in a local network), this should hold the session alive. Perhaps not a solution for all scenarios, but for most.

I try my best Version 0.1.1 is on GitHub and should be picked up by the module repository soon.

Not yet, but that should be easy to add as a module config option. I'll try to get around to it this week. Stay tuned.

This happens when the user PHP runs as isn't the owner of the cache files. The file compiler tries to update the cache files with the modification time of their originals, and while writing to that file can succeed through group permissions, updating the modification time fails unless issued by the owner. Clearing the cache removes the cache files and recreates them with the PHP user as the owner, so the problem is gone.

Shouldn't it be enough to exclude subdir requests from that last https rule? # Redirect all requests to subdir RewriteCond %{REQUEST_URI} ^/?subdir(/|$) RewriteRule ^/(.*) http://www.example.com/$1 [R,L] # Make sure to use plain http for subdir just in case... RewriteCond %{HTTPS} =on RewriteCond %{REQUEST_URI} ^/index.php\?it=subdir(/|$) RewriteRule ^/(.*) http://www.example.com/index.php?it=subdir$1 [R,L] # Rewrite all other requests to https RewriteCond %{HTTPS} !=on RewriteCond %{REQUEST_URI} !^/index.php\?it=subdir(/|$) RewriteCond %{REQUEST_URI} !^/?subdir(/|$) RewriteRule ^/(.*) https://www.example.com/$1 [R=301,L] Note the "(/|$)" (either forward slash or end of string) I've added after subdir in the patterns to make sure that it matches exactly.

When you get around to it, make sure you use this approach: Do NOT uninstall the module in the backend, or the blog module may consider itself not yet configured when you reinstall it, redirecting you to the install wizard instead of the dashboard (where the install wizard then errors out since the pages, fields and roles already exist).

@Rajiv: Please use the version you can download at https://github.com/BitPoet/Blog/archive/dev-3x-compat.zip The link by @flydev accidentially linked to the original, unpatched branch of the fork.

Have you added TextformatterHannaCode to the blog_body field's configuration?

Do you mean this button? MediaLibrary is meant to avoid adding files and images to every page anew. Such functionality would copy the selected file/image over to the current page, which would be the opposite. I seem to recall that there's been a module somewhere in the forum that lets you add files or images from other pages, you might try google search with site:processwire.com/talk/ to find it. It should be possible to tweak that module then to only allow MediaLibrary pages if that is your requirement.

Hi @MaryMatlow, that's actually a question I haven't yet thought about, since the pages I use it in assembles their navigation menus through more detailed selectors. I don't know if you could exclude it from your navigation by adding a "template!=MediaLibrary" somewhere. I'll give it some thought and post back here.

That's because ~= uses fulltext indexes for natural language search, which is limited by its ft_min_word_len setting that defaults to 4 characters (unicode code points). PW's selector operator docs explain that. You could lower that setting, but you have to be aware that MySQL doesn't support proper detection of word boundaries for Asian languages. Recent MySQL versions (>=5.7.6) have the option to let an ngram parser divide sequences of unicode characters into groups (ngrams) of a configured length, but that is also quite a fuzzy thing and may summarily not give the results you want. Usually, Oracle's recommendation is to use a third-party search engine that comes with a dictionary-based preprocessor, e.g. the Sphinx engine.

The stackoverflow post relates to Microsoft SQL Server, not MySQL. Searching for Unicode characters works fine in PW. If your characters get stripped, my bet is that they aren't valid utf8, which means the script itself is in another encoding, and/or the webserver announces a different one. I just tested by creating a page titled "你好 World". Running <?php foreach($pages->find('title%=你好') as $p) { echo $p->id . ": " . $p->title . PHP_EOL; } returned exactly that one entry as it should. To check, save your test code as a script and set your editor to utf8-encode it. Don't trust the command line. If that works, check the encodign headers of the webserver using the developer console (F12).