BitPoet

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).

Have you tried doing if($page->repeater_field->find("pagefield.status=on") ) { // ...whatever... } ? (untested)

The first thing I'd look at are name resolution issues, like e.g. ipv6/ipv4 priority problems (::1 vs. 127.0.0.1 when resolving "localhost"). These often show as extremely slow database connections and are especially noticeable in the backend. It helps to specify the IPv4 address instead of hostname in $config->dbHost if that is indeed the cause.

Either that or test-drive the upgrade on a local development system. Which, of course, doesn't substitute for having a working full backup of the live site at hand any time you make changes there, but it should rule out issues with older modules (few as they are).

[X] This one: done.

The last one's the one I'm talking about.