ceberlin

Hi Jasper, I was ready today to trying the new version.

After installing, when going to edit the module's prefs, I get a blank page and this:

Error: Using $this when not in object context (line 202 of /.../site/modules/SchedulePages/SchedulePages.module) 

My problem I have with the select that needs plenty of pages as sources is that there are so many cases in real live where you need typical standard selections, like a full standardized list of countries. Making pages for 100 countries or 300 airline codes does not sound elegant to me. 

So I am glad there is an alternative with that module. That's a good hint. (Although I also feel that I have almost too many modules running already)

Hi Ryan, this sounds VERY interesting. Does that mean that the PageLinkAbstractor is now obsolete? And if not de-installed (because that could mean broken links and lots or repair work, if I see this correctly) - could there be a conflict having both active at the same time?

I am using the latest PW dev version together with the teflon2 dev version (which I like a lot, I must say)

OK then I need to watch out for modules which might be disturbing the functionality.

My first thought was that the after-save- Module, which alters the save button behavior was the bad guy, but after disabling it the save still did not work.

If I use the button at the bottom for saving a page, everything's fine.

Interesting that that sticky button works ok, when I switch back to the default template.

Hi, I am on PW dev and tried Teflon 2 dev.  The sticky save button at the top does not seem to save anything.

The default admin template does work.

Am I the only one? (do I need to search  for other reasons?)

Hi, I find your module an interesting alternative to "minify" but I find the instructions confusing.

- There is no "templates" folder inside of the "modules" fiolder, You mean the "site" folder?

- Does your php file needs to be in the root of the template folder or can it reside in a subfolder?

- "All CSS files have to exist in processwire" You mean all css files, external or not, are loaded into PW's config-> array?

- CSS files need a certain order. Is this order preserved after minifying?

- <?php echo $modules->get('MarkupCSScompress')->render(); ?>

Do you target the module file with this? Or the file that was copied into templates and is this the right code for that?

Hi Jasper, great, I will download the update. Is there a way to collect the logs but stop the execution?

Right now I don't want the module to be active as my client would not tolerate this before the problem is found.

What to I need to comment out to have the logs saved but the unpublishing not executed?

(Or maybe that would be a cool add-on for the prefs. Do not actually publish/unpublish but send an email reminder instead.)

Some more thoughts on this:

1. Empty fields.

Maybe the code needs a revision for this.

Pages where the unsubscription field is empty should never be executed, not even with weird time() results. But that is what happend here.

Maybe the empty field can be something else than 0 so that $p->publish_until > 0 might not work in all cases (if it was NEVER set) ?

2. time() / $time

Assumed that the Provider is correct when saying that the server time here is "always correct" and thoroughly checked...

The effect happened not completely out of the blue but when I worked on a panel that displays a word clock with local times (a html5 canvas) on the contact page.

Maybe fiddling with php 5.3 timezones calculations came in the way for the module?

Somewhere during development a side effect could have happend. For example:

I used date_default_timezone_set() a lot to calculate local times for each clock. And I used a variable $time for that localized time, which you used as well a a global variable for the individual page. (I am now using $time1 and no trouble so far.)

Hi Jasper, no worries... I like the module and need much, what it does, and I am positive that this  issue can be fixed.

To answer your question: The fields were in there but since our website is only a few weeks old, those fields were still mostly empty (no content, also no default content).

Server Time problems? Provider says "no" - but who knows. There domain uses the cloudflare service, so this might play a role.

Hi, I try the move the discussion over to the module's thread and will reply there...

http://processwire.com/talk/topic/711-release-schedulepages/page-3

By the way: I did not uninstall it - I believe there will be a fix soon and I did not want to loose data from the published_from and published_until fields.

I just shut off the execution of the module by commenting out the 2 "save()" commands in its pubish / unpublish functions.

(A bugfix-module update would automatically reactivate it by overwriting this.)

Hi Formmailer, very useful module.

I just want to mention that some of us have problem with it under PW 2.3.1 DEV.

See this thread:

http://processwire.com/talk/topic/3768-processwire-231-dev-branch/page-2

What happend to me: Out of the blue the module was unpublishing every single page on my system which had a template with your scheduer fields.

Also Ryan found an issue, see his comment #36 in the mentioned thread.

It's possible that your index tree needs a refresh. Try dragging the entire /en/ page (tree) below a new parent. Drop it there and let it sit for 5 seconds. Then drag it back to have home as the parent. Now try your query again and see if it's showing up when using has_parent. 

Looks like this was the KEY HINT to solving all our mistery bugs for find() and get().

(The most scary bugs are features which work only sometimes, with no reproducible pattern.)

 THIS TIP SHOULD BE THE #1 HINT IN CASE OF TROUBLE.

I know were it came from: We built one language tree first with all its many sub-pages.

Then we duplicated the tree to make that the basis for language translations.

So the clone module might have an issue - or it should just be common practice to 

refresh indexes manually this way after an excessive cloning.

Thank you again for your time and valuable support!

Hi Pete. thank you very much for this confirmation. This was the last big unsolved "mystery bug" from my list. 

Maybe it is time now to contact the author...

Unfortunately theres one more question:

Error: 
Exception: DB connect error 1203 - User already has more than 'max_user_connections' active connections (in /.../wire/core/Database.php line 68)

Are these too many users at the same time on my website or is this a problem with the new driver?

I will also ask our provider about this. (This error is completely new: I was running an external validator. Maybe this thing was too busy.)

Hi, what you have seen is an emergency setup. 1-Click-Publishing and Batcher came handy to get everything up and running again without much detours. And max rights for my editors today were needed so they could continue. I know them well enough to trust them (and a database backup is ready too). 

There were a couple of important hints. Good news: All things are coming back to normal now.

• There were no outsiders and no hack: "Guest" in the log means also internal processes. (Batcher was not involved: It reports in the logs who run it.)
• The dev version (especially that one file) was not the problem but only happend to be updated at that time by coincidence. I am now on the latest dev and things look fine.
• The rights problem might be connected to the reversion to an earlier PW wire release which was the first measurement taken when a dev file was suspected. Turned out: The problem was "cured" with a problem.
• The mass unpubishing might be in fact be connected to that module you mentioned. That is my missing link!
• I check now with the provider whether there was a problem with the server time, Sounds reasonable; that would explain everything.

Thank you 100000 times for not leaving me in the dark with that obscure phenomen.

Hello Ryan, thank you for your time looking into this. If I placed a message at 2 spots, I am sorry. Maybe by mistake. You can imagine what the effect of this change is, I am flooded with phone calls from editors and started to pin down this subject several times today already fulll of interruptions.

Funny thing is: everything worked for weeks and the only thing I was permanently keeping up-to-date was the dev version of wire since the switch to PDO.

Shortly after the 21th July update things went bad and I discover more and more, to what extend.

We use multi-language-supprt but not LanguageSupportPageNames.

(We solved this differently by allowing local editors to changes file names in language branches and catch files in find() and gat() over a permanent field.)

Before the dev update from 21.July I was running the previous dev version. No problems at all.

It can be, that the permissions are changed at runtime. If I look at the templates permission settings, everything's fine there.

Yes I use field-permissions, basically to secure certain fields that are too powerful like html textareas without filters for certain JS.

(What was not changed in runtime bur for real was the unpublishing rights)

Fields permission: From what I know, first the permissions for a page are set and then there is an exception for certain fields that are more restricted, correct?

Our templates are as simple as they can. We only display, we do not save.

One exception to mention:

Looking for save() revealed a template in my backups which was in use at the time when the trouble started. That

shows an analog clock. It has a save() in the JS somewhere. (This script is not in use any more because we found something better.)

Was that the trouble maker and not wire? File is included as "oldfile.php".

Addition: The new Clock Code (march.js) we use also uses save() in it's JS .... this has somehow to do with drawing inside of a canvas.

And the external script is handled by PW like this:  $config->scripts->add($config->urls->templates . 'scripts/clock/march.js');

Maybe there something gets executed that should not be.

I can say now that the time the trouble started was exactly when implementing this widget. Thats what I meant when saying 

we were not changing things in PW but were only adding visual gimmicks at that time.

Out of the sudden, not only lots of pages got unpublished but also rights are revoked.

I set all rights in the templates - very fine grained.

But Editors have no access and if I as a superuser look at the page settings, I see only rights for the superuser.

The long list of rights is gone. There is only "Superuser *" (or sometimes page-add rights are still there)

No way to reset that by going back to the template and hit "save" again.

When that happend I was not doing anything. In the night before we had updated to the newest dev version

because there was a function we needed.

Used system:

PW Dev Version

Roles

Permissions

Page Permissions

Page Edit Field Permission

Finding that out of the sudden a "guest" batch-changed 700 file settings scared the hell out of me, I must say.

It scared me even more that I cannot see a pattern, why some files were changed and others not.

Glad to hear that "guest" was probably not a person and no hack, but only a script gone wild.

I really would find very useful if it was recorded somehow, what script was involved. But that is maybe to much to ask.

Today we had an incident were lots of pages got unpublished. 

There were no normal editor activities around that time and there was no clearly seeable pattern.

The logs never should say "guest" if the api does something, better would be "system" or "API" and even better, which script.

Because of "guest" I immediately thought of a hacking attempt to the batcher, for example. But we found no sign of hacking.

700 "unpublishing"-changes in little time - this was a script and no person, for sure. We investigate at the moment.

Hi, there were registered changes here today from a user "guest"... how can that be?

Yes that worked. The error is gone. Thank you.

Hi, I have a funny problem with redirects.

I want to redirect from

/en/index.php   (which was a valid link on the website before the update to PW)

to

/en/

Works perfectly. 

But if I open the redirect settings for editing, the"from" link is empty and I get a warning "enter valid url".

This works so far, I guess I was mixing here page arrays and single pages and find() returns an array.

$page->rootParent->child("page_key=check-status")->url

(I wished there were more examples in the tutorials)

Old modules from the past, I see.

We have some problem here with the find() and I wanted to be sure to rule out some possibilities.

I find unusal that the PW created database turns out to be a mix of MyISAM and InnoDB tables,

Most collations are utf8_general_ci, but I fould also ascii_general_ci and _latin1_swedish_ci.

Maybe this is coming from modules...

I am not a database pro, I am designer, but to me this looks like potential trouble with searches, sortings and so on.