kongondo

A starting point maybe? http://modules.processwire.com/modules/fieldtype-secure-file/

https://processwire.com/talk/topic/3843-how-to-define-the-404-page/

Hi mauricius, Tried to install this on a PW 2.5.25 dev site and got the following error Fatal error: Class ProcessSlider contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (ConfigurableModule::getModuleConfigInputfields) in F:\xampp\htdocs\dev\site\modules\MarkupSlider\ProcessSlider.module on line 648 I didn't have time to investigate further. Thanks.

@Richard, glad you got it sorted. Btw, I have another version that recursively searches through folders, sub-folders, etc....The Standard PHP Library (SPL)) is really cool

Simple answer is that @Valan had a need and commissioned me to develop this . Seriously though, mr-fan already covered it brilliantly. When I get some time, I'll post some other examples.

UNTESTED, probably have some typos + poorly formatted code (I gotta run...) You want to add this to your template file....Wrap it around code that ensures only Superuser can load the code... //absolute path to a directory called 'tmp' within the site folder where we have our images $dir = $config->paths->site . 'tmp'; $addAndPublish = false;//true if you want to publish on save //prepare some variables we'll need later $a = 0;//for photo pages count $failed = array(); $parent =$pages->get('/portraits/'); $t = wire('templates')->get('your-portrait-template-name'); //if we found the directory (here we use Standard PHP Library (SPL)) if (is_dir($dir)) { $directory = new RecursiveDirectoryIterator($dir, FilesystemIterator::SKIP_DOTS); //iterate through each file in this directory foreach ($directory as $path ) { set_time_limit(30);//we try to avoid timing out //Remove and delete invalid file types $validImagesExts = array('jpg', 'png', 'gif', 'jpeg'); if($path->isFile() && !in_array($path->getExtension(), $validImagesExts)) { unlink($path);//we delete the invalid file continue; } //if valid image file we create a page named after it and later save it to the page if($path->isFile()) { //we are ready to start creating pages... $p = new Page(); $p->parent =$parent; $p->template = $t; $title = $path->getBasename('.' . $path->getExtension()); $p->title = $this->sanitizer->text($title); if (!$p->title) continue;//skip to next if no title found (just in case) $p->name = $this->sanitizer->pageName($p->title);//sanitize and convert to a URL friendly page name //check if name already taken if($p->parent->child("name={$p->name}, include=all")->id) { //if the same name already exists, add it to the $failed array [to display to user in error later] and skip to next title if ($path->isFile()) { $failed [] = $path->getFilename(); } continue; } //if add and publish is false, we save new page unpublished if (!$addAndPublish) $p->addStatus(Page::statusUnpublished); $p->save(); //add image to the page and save again $p->images_field->add($dir . '/' . $path->getFilename()); $p->save(); $a++; unlink($path);//we delete the temp file } }//end foreach //delete the tmp directory wireRmdir($dir, $recursive = true); //create a string of "failed" category titles to add to error message $failedTitles = implode(', ', $failed); //give the user some feedback... if($a > 0) echo 'Added' . $a . 'Portraits<br>'; if($failedTitles) echo 'Some Portraits not added because names already in use. These are:' . $failedTitles; }//end if (is_dir($dir))) else echo 'No Such Directory Found!';

Btw, thanks, your question made me realise that the code around the strip_tags need to be optimised anyway...That bit of code should only load when post small is set to true.

Glad you got it sorted. Could I suggest that you direct the Autolinks question to Ryan? Maybe there's a way around the bottleneck...How many pages were you trying to load at once, btw?

@Gazley, Must be at your end mate. I haven't encountered this nor read anywhere that strip_tags is slow. As you can see in this demo with +10K posts, showing 20 posts per summary page with a summary limit of around 500 words each and WITHOUT ProCache, PW loads the page in about 2 seconds.. http://demo.kongondo.com/blog/ And with shorter summaries: http://demo.kongondo.com/blog/posts/

Is it solved then?

The answer is actually in the error message. Your assets directory seems to be locked down for writing. Does that happen only with Modules Manager or throughout your site? If the former, you might want to ask your question in Modules Manager support forum. There was a similar issue a while back. If the latter, have a read at this as well: https://processwire.com/docs/security/file-permissions/

FieldtypeRuntimeMarkup and InputfieldRuntimeMarkup Modules Directory: http://modules.processwire.com/modules/fieldtype-runtime-markup/ GitHub: https://github.com/kongondo/FieldtypeRuntimeMarkup As of 11 May 2019 ProcessWire versions earlier than 3.x are not supported This module allows for custom markup to be dynamically (PHP) generated and output within a page's edit screen (in Admin). The value for the fieldtype is generated at runtime. No data is saved in the database. The accompanying InputfieldRuntimeMarkup is only used to render/display the markup in the page edit screen. The field's value is accessible from the ProcessWire API in the frontend like any other field, i.e. it has access to $page and $pages. The module was commissioned/sponsored by @Valan. Although there's certainly other ways to achieve what this module does, it offers a dynamic and flexible alternative to generating your own markup in a page's edit screen whilst also allowing access to that markup in the frontend. Thanks Valan! Warning/Consideration Although access to ProcessWire's Fields' admin pages is only available to Superusers, this Fieldtype will evaluate and run the custom PHP Code entered and saved in the field's settings (Details tab). Utmost care should therefore be taken in making sure your code does not perform any CRUD operations!! (unless of course that's intentional) The value for this fieldtype is generated at runtime and thus no data is stored in the database. This means that you cannot directly query a RuntimeMarkup field from $pages->find(). Usage and API Backend Enter your custom PHP snippet in the Details tab of your field (it is RECOMMENDED though that you use wireRenderFile() instead. See example below). Your code can be as simple or as complicated as you want as long as in the end you return a value that is not an array or an object or anything other than a string/integer. FieldtypeRuntimeMarkup has access to $page (the current page being edited/viewed) and $pages. A very simple example. return 'Hello'; Simple example. return $page->title; Simple example with markup. return '<h2>' . $page->title . '</h2>'; Another simple example with markup. $out = '<h1>hello '; $out .= $page->title; $out .= '</h1>'; return $out; A more advanced example. $p = $pages->get('/about-us/')->child('sort=random'); return '<p>' . $p->title . '</p>'; An even more complex example. $str =''; if($page->name == 'about-us') { $p = $page->children->last(); $str = "<h2><a href='{$p->url}'>{$p->title}</a></h2>"; } else { $str = "<h2><a href='{$page->url}'>{$page->title}</a></h2>"; } return $str; Rather than type your code directly in the Details tab of the field, it is highly recommended that you placed all your code in an external file and call that file using the core wireRenderFile() method. Taking this approach means you will be able to edit your code in your favourite text editor. It also means you will be able to type more text without having to scroll. Editing the file is also easier than editing the field. To use this approach, simply do: return wireRenderFile('name-of-file');// file will be in /site/templates/ If using ProcessWire 3.x, you will need to use namespace as follows: return ProcessWire\wireRenderFile('name-of-file'); How to access the value of RuntimeMarkup in the frontend (our field is called 'runtime_markup') Access the field on the current page (just like any other field) echo $page->runtime_markup; Access the field on another page echo $pages->get('/about-us/')->runtime_markup; Screenshots Backend Frontend

Here's a similar gem: https://processwire.com/talk/topic/4105-module-create-a-pages-findquery-as-a-field/?p=40411

It is the title that ticked me off. For an 'experienced' publisher like tutsplus I expected at least the title to match the contents. For such a big outfit, my cynical side is telling me they knew exactly what they were doing....they know that was not an introduction to ProcessWire. Compare that to this introduction to Craft CMS. OK, so the authors are different but I expect articles are not published without going through some editorial process. Anyway, am good now... Edit: Ah, I see, Felix also commented about the Craft CMS intro...

Thanks for that MichaMichaMicha, At first I was excited about the article...people have been waiting for this....Then reading it, it turns out (not-so-under the hood) this is an article about WordPress! What cheek! Underneath all the veneer about talking about PW, he/she is just bashing PW and not really saying much about its strength. Nothing about its raw power! I don't think the writer has even used PW before!! What a load of tosh! My frustration is not vented at you....but the writer of the article... That was supposed to be an intro...for crying out loud! .

Sorry for the late response. I don't quite follow your question. Did you find a solution?

@adrian, Just to let you know that I've added all your requests the module's GitHub issues so that I don't forget. As for the append vs overwrite issue, append seems to be quite tricky. It would need to find the last populated row and append from there. But finding out what the last row can be tricky, especially where we also allowed 'empty values'. I don't know if this makes sense. Anyway, will have a think about this one. Btw, the suggestion about custom PHP code to find row/column matrix pages is a powerful one and will lead to many possibilities, thanks.

Just hit the refresh button...no need to uninstall..

Do you mean to allow empty values in both CSV imports and manual entered values? Both should be quite easy to implement. I think I'll implement them as separate options though. Overwrite vs Append: Off the top of my head I think it overwrites. I'll have to confirm this one. Export to CSV: Good idea. Added to my @todo

Seen this? Site-wide File Manager Support forum: https://processwire.com/talk/topic/630-module-manage-files/ Related: https://processwire.com/talk/topic/11040-visual-page-selector-commercial-page-picker-module-for-processwire/

@mauricius. This is a very beautiful implementation Welcome to PW and the forums...

Should the {title} be name? Since it is used to form the URL? Just curios whether the module will convert it to name (haven't used it before)

You have two options for the dropdown: Page Field or Select Options Fieldtype

That's a better description...Like @tpr has suggested, this would be better managed on the admin side rather than in an include file for at least two reasons: 1. Your images will have a description - no need to type that text in some template file where your client/editors will not be able to change it 2. Dynamism...in case needed in the future. Here are some options: Option 1: Create an image field (e.g. call it content_header). Attach this image to the template used by your parent pages (Whale, Guppie, etc). I am assuming all these parent pages have a single shared template (please note, I am talking about a template here; not a template file). Image fields have a description text area. Use that for your 'brief descriptions'. content_header->description will give you access to those descriptions. More here on image fields. Then on the children pages' template file(s) call on their parents' image field and description...e.g. $page->parent->content_header->description Option 2: Create a dedicated page to hold all the content headers and their descriptions. Let's call it 'Content Headers'. Add one image field to it that accepts multiple images. Add your '25' images named similar to your parent pages, e.g. whale.jpg, guppie.jpg, etc (if practical, or use some other naming format). I can't remember if you can use the API to find an image using its name (i.e. $image->basename). Anyway, you can activate the 'tag' text area of an image field (in the field's settings). In that case, no need to give your images any specific name. Then, give each image a tag that is identical to your parent pages names or titles. You can find each specific image using their tag, i.e., $page->images->getTag('mytag'); Or, in your case you refer to the dedicated page, e.g. $p = $pages->get('name=content-headers'); $chImage = $p->content_header->getTag("$page->parent->name"); If you gave the whale header image a tag called 'whale', then, when viewing Whale's child pages, this image will be retrieved. The advantage here is that you can edit all your content headers in one place. Option 3: If your descriptions are quite long, then, create a dedicated text field(s) and a separate image field using either of the above options Option 4: I think you could also use repeaters or PageTable(?) Haven't tested the above code and I have been away a while, so, there could be other better ways to accomplish what you are after.

Although it works, seems a bit strange that you are exploding the page's URL string to get (I suppose) the name of the parent page. ProcessWire already has methods and properties to get you all the information you need about a page (similar to my example above). What might be a 'better' way depends really on the answer to the questions: What is the content of headerImage.inc (is it just an image?) Is that content dynamic in itself (i.e. will you be editing headerImage.inc) or static? Otherwise, like I said, there could be a dozen (better ) ways to achieve the desired effect. You could still get away with one or two templates. Depending on the content of headerImage.inc you could have for example a single page with all the header.incs as fields, a single image field that holds multiple images, several pages, etc. Hard to answer without answers to my questions above ...