kongondo

@BitPoet, Looking good! You might want to consider joining forces/exchanging ideas with @GuruMeditation who is also working on a native PW forum

Try to set max exec time within the loop itself, inside your if block $page->setOutputFormatting(false); set_time_limit(60); If memory is a problem, you might also want to free some memory by adding the following after WriteLog. WriteLog("{$internal} saved"); wire('pages')->uncacheAll(); // free some memory

Thanks. Good idea. Will provide the method.

No worries. As for general API, yes you can override (and even create methods and properties) on the fly at runtime since PW is an OOP application. So (and I assume you probably know this) you can do: // where such a field does not exist (i.e. this page has no summary field but we create one at rt) $page->summary = 'My nice summary'; // and you can also do, replacing the saved page title at rt (but not saving it) $page->title = 'My replacement Title';

Mod Note: @Jason, Please try not to double post. You asked the same question earlier today . Merging this thread with MarkupSEO's support forum since your question is really about that module.

Have a read here...but good to read the whole thread

@Macrura, Thanks for catching this. You will notice the same error if you tried to rename a FieldtypeConcat field. The error occurs because these Fieldtypes do not create a database table, i.e. there is no field_my_runtime_field table. MySQL throws the error since it can't find such a table on file, i.e. there is no field_my_runtime_field.frm file (every MySQL table is represented on disk by a .frm file that describes the table's format). It throws the error in Fields.php, in the __save() method, here. Although the method is hookable, I'll have a talk with Ryan to see what's the best way to handle this. Edit: Forgot to provide a temporary solution: As we know, the names of fields themselves are stored in the 'fields' table. As we wait to resolve this, we can always change a fields name there. Not ideal, I know, but we will get to the bottom of this. Edit 2: Issue fixed in this commit in ProcessWire 2.7.2 (dev)

Maybe even a very tiny 'prettifier' would do....hmmm

Planned for version > 1, maybe 2nd release

Thanks, might just do, considering my growing issues list. I also have @jlahijani list of ideas to consider.

Drag and drop to sort or to upload? Both are already implemented

Simplest way I can think of is to use PHP substr and strip_tags. The latter is very greedy so you need to tell it what to avoid [allowable tags]...(it get could messy very quickly). Anyhow, this is how we do it in the Blog module using those two PHP functions.

@Macrura, Glad you liked it. Like I hinted in my first post, your custom menu idea was one of my inspirations, so thank you too . It still needs some work and re-factoring but time is my worst enemy (currently? always? ). Let us know how you get along.

Rather than reinstalling and reimporting from your old database, you can do the following: Do not test this on the production server, obviously Back up the database of your current Blog install Import your backed-up database into a fresh Blog install on your local/test server. This Blog install should not have 'Schedule Pages' installed (just to better illustrate the steps below) Check that this test Blog works fine OK, now the fun part. Install and configure the module Schedule Pages. If you do not yet have LazyCron installed, ProcessWire will complain that it cannot install Schedule Pages since a required dependency is missing. LazryCron ships with ProcessWire so, in that case, head over to modules -> install to install it. The module 'Schedule Pages' will create two fields with the names 'publish_from' and 'publish_until'. Give them appropriate labels if you wish, e.g. 'Auto-publish from' and 'Auto-unpublish on' respectively. Make sure you read the module's usage notes (e.g. that you need to confirm LazyCron is working properly on your server) Add the above two fields to the template 'blog-post' and save. If this had been done via the Blog Install Wizard, these fields are placed at the very top of the list of fields on this template, just above the 'blog_date' field and given a width of 50%. OK, off to the database we go. In phpMyAdmin or similar, go to the ProcessWire database where you have your (test) Blog installed and find the table 'modules'. In that table, looking into the 'class' column, find the row 'ProcessBlog' (see screenshot below). In the column 'data' you will see saved Blog configurations (see example code below). Find and edit the entry 'schedulePages'. In your case it should be empty and looks like this: schedulePages":"". Modify it to be like this: schedulePages":1. That 1 tells Blog that use of 'Schedule Pages' is true. If using phpMyAdmin, it has inline editing (double click on what you want to edit and make your edits and mouse out to save) In your Blog's Posts Dashboard, under 'Quick Post' You should now see two entries 'Publish from' and 'Publish until'. When editing/creating a post, you should also see the two fields that you added to the 'blog-post' template. Create (but do not publish) a Test Post to test auto-publishing/unpublishing at the dates you set. Note that since the module 'Schedule Pages' uses LazyCron, it needs a browser visit to trigger it. Visit your post (in the frontend, in a different browser where you are not logged in) at a time near its scheduled auto-publish time. You should get 404. Reload your browser some time after the auto-publish date and you should see your 'Test Post'. You are done database blog config database blog config without 'schedulePages' enabled {"blogFullyInstalled":1,"blogStyle":"1","schedulePages":"","commentsUse":1,"templateFilesInstall":"2","tagTemplatesFields":"blog","blog":1020,"blog-posts":1021,"blog-categories":1022,"blog-tags":1023,"blog-comments":1024,"blog-widgets":1025,"blog-authors":1026,"blog-archives":1027,"blog-settings":1028,"blog-asc":1032,"blog-dnc":1033,"blog-dc":1034,"blog-rposts":1035,"blog-rcomments":1036,"blog-broll":1037,"blog-tweets":1039,"blog-pauthor":1040}

@BernhardB, yes, I have considered it. Will look further into it, thanks.

Tell me about it. I opened Macaw and got a headache straight away .

Not wild not silly... Yes, you are covered ...but currently only audio + video. Documents are trickier, except for PDF. Still mulling using a different jQuery plugin vs fancybox?

Getting warmer....(OK, so my icons suck, but hey...we're 75% there. ).. Page Edit List View Page Edit Grid View Page Edit Insert Media ProcessMediaManager

The Macaw thing is on sale (going for $49)...if anybody's interested...

Try removing the isset condition... <?php if($page->slideshow->count()):?>// or below if this doesn't work.. // <?php if(count($page->slideshow)):?>

Works fine here: PW 2.6.21, PHP 5.4.22

Yes. Use getQueryLog() (will only work with debug on) See example code here: https://processwire.com/talk/topic/11483-duplication-in-query-results/?p=106994

My bad... I still haven't had time to re-up Blog's documentation. Meanwhile, please access it on WayBack Archives: https://web.archive.org/web/20141114094607/http://www.kongondo.com/tutorials/specific-features/creating-a-blog-in-processwire/render-posts Have a read of the tutorials there and you should be fine

Errors in ProcessWire logs? A server error, etc?

I am guessing they are related... Applying this to your case... It means line 119 refers to the script where the header() invocation failed (i.e. in shutdown.php). However, the source is line 19 in WireData.php. In my PW version, that's the beginning of the Class WireData. So unless you touched that, then it is probably something calling WireData.php that's failing.. Hard to tell though. The last time I got this error was trying to delete some page via API and it didn't work and it got stuck in memory and had to restart Apache...I know this is probably not too helpful...