ProcessWire Dev Branch

[Soma]

Ok, weird. Since this was an older 2.3 install, I had to change my password.

It looks like after that update, the session modules weren't listed anymore... hmm

I then did a "Check for new Modules", and it logged me out. After loggin in again it was all there suddenly. It seems it was the modules cache, since "Check for new Modules" clears cache. Pitty.

[Pete]

I'm getting this error after replacing the wire directory on WAMP localhost to upgrade a test install:

2013-07-11 19:47:14    ?    http://localhost:82/?/    Error:     Exception: SQLSTATE[HY000] [2002] A connection attempt failed because the connected party did not properly respond after a period of time or established connection failed because connected host has failed to respond.   (in D:\wamp\www\pw\wire\core\ProcessWire.php line 106)

Any ideas? I've definitely got PDO enabled - PHP version is 5.3.13

[WillyC]

/site/config.php

$config->dbHost = 'localhost';

changes.to 

$config->dbHost = '127.0.0.1';

o lo contrario ?

[Pete]

Thanks - that worked

[ceberlin]

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.

I think this is the bad guy on GitHub: 

Improvements to the "who can access this page" output in ProcessPageE…

Used system:

PW Dev Version

Roles

Permissions

Page Permissions

Page Edit Field Permission

[ryan]

@ceberlin: not a problem, but for the future please try to avoid posting the same message in two topics–I see this same message as a new topic, so I'll delete that one and reply to this one. 

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

It sounds like you are using a module that modifies ProcessWire's default access control: Page Edit Field Permission. So it's very possible that the rights you see in your page settings are incorrect. Instead, pay more attention to what your templates actually say, and how you've configured the PageEditFieldPermission module. Those have authority. The info you see in page settings is an informational-only table that reflects known static permissions and says nothing about runtime permissions attached from other modules or hooks. 

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.

Most of the changes in the dev branch are specific to the LanguageSupportPageNames module and multi-language support in general. Are you using LanguageSupportPageNames or any kind of multi-language support?

When you updated to the newest dev version (2.3.2), what version were you running before that?

I think this is the bad guy on GitHub: 

Improvements to the "who can access this page" output in ProcessPageE…

I replied to your comment on GitHub: 

Ryan wrote: I'm not sure what you mean. What line do you see that you think is problematic? This function simply generates a table to display what roles and permissions it thinks are accessible on the page. It does not modify, save or delete anything, it only generates output. It's also very possible for this info that it produces to be wrong, as it only knows about static permissions, not runtime permissions. If you have modified anything about the way ProcessWire handles access control at runtime (via modules or hooks), the results that this table may not be correct, in which case its output can be ignored.

Permissions

Page Permissions

Page Edit Field Permission

 

 

Why linking to the mod settings pages in the admin of your site? I was thinking it might be because you want me to look at your settings for those modules, but note I can't see them since I am not logged into your admin. 

Are there any other 3rd party modules you have installed? If so, can you mention them, or post a screenshot. We'd want to see all modules that appear on the "site" tab of your modules screen.

Also, since all of this is rather mysterious, I would also suggest checking your template files. Do you have any instances of save() in any template files or files they include? If I had experienced the same issues you have, the first thing I would do is check where I am saving pages (or anything else) in my site. I would suggest doing a:

grep "save()" /site/templates/*

Please post the code for any sections that perform a save of anything in your template files. 

[horst]

@Ryan:

I have tried installing the latest dev version today. The Setup tested for PDO and says: ok! - but afterwards I saw that I haven't enabled it. So I haven't investigated further, but maybe it is better to do a more advanced checkin the routine: https://github.com/ryancramerdesign/ProcessWire/blob/dev/install.php#L152

like

    if(class_exists("PDO") && defined('PDO::MYSQL_ATTR_INIT_COMMAND')) {

asking for class_exists('PDO') can result to true without installed php_pdo_mysql

[ryan]

asking for class_exists('PDO') results to true without installed php_pdo_mysql

That seems unusual that the class exists even though it isn't installed? Thanks for finding that and posting a fix, I will update! 

…Though if the PDO class exists, then the PDO:: constants would presumably also be defined (since they are defined in the class). So I think another type of check would be necessary. But what kind of check, I have no idea. I'm going to hunt around stackexchange and maybe look into what other CMSs using PDO are doing.

[horst]

Ryan I simply have checked with disabled php_pdo_mysql it results to false

and with enabled php_pdo_mysql it results to true

The MySQL-Driver specific Constants are not known by the (base?) PDO-class. They are only known if the driver is installed.

[ceberlin]

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.

[ryan]

I don't think that the oldfile.php is the problem, because it has a javascript save() (whatever that refers to), not a ProcessWire one. 

But looking in your Modules.pdf, I can see you've got a large amount of 3rd party modules installed. The more 3rd party modules you have installed, the more you have to keep track of in terms of versions and potential interactions. This is true of any CMS. It really expands the scope of where the problem might lie. I can also see by the PDF that you've switched back to PW stable? Just wanted to confirm that you are no longer on dev? If that is the case, make sure that you replaced the entire /wire/ directory when switching between stable and dev. The best way to do that is to rename the old wire directory, and then upload the new one from scratch, then remove the old one once you are sure it works. 

So far it sounds like we can narrow the issues down to two things: #1) large amounts of pages got unpublished; and #2) template access control settings disappeared. I'm not convinced that these things are related. So lets take a look at them separately. 

For #1 I would look at what modules can publish/unpublish, because ProcessWire has no mass-unpublishing capabilities in the core. In looking at your modules list, it looks to me like: SchedulePages, Page Publish/Unpublish and Batcher (if you had it installed). Of those, only SchedulePages and Batcher can do mass unpublishing, and it doesn't look like Batcher is installed.

So I took a closer look at SchedulePages: the module looks to be nicely coded, but I spotted a problem on this line. 

// Select published sites with a publish_until date add them to an array.
$published = wire("pages")->find("status=published, publish_until>0");

It's referring to "status=published" and "published" is not a status keyword recognized by ProcessWire. I think that the author really meant to do: "status<" . Page::statusUnpublished, because there is no published flag in PW, only an unpublished flag (since it's technically a bitmask). Why don't you try to run this selector "status=published, publish_until>0" in your Setup > Selector test, and see what it finds. Reading the rest of the function in SchedulePages, it still seems unlikely that this would be responsible for your unpublishing unless your server's system time inadvertently got reset to something earlier than it was supposed to be? For instance, what if your web host installed an update and had the server's time messed up for a few minutes? That could feasibly produce a mass unpublish event since this module performs unpublish actions connected with time. 

Edit: also want to add that it sounds like in your situation with numerous editors, a 1-click "Page Publish/Unpublish" module might be a little bit dangerous, as someone could unintentionally unpublish a page very easily without meaning to. You might want to uninstall this module, just to rule it out as being a problem. In this day and age when we can butt-dial people on our cell phones, we can also click links without knowing it. So a 1-click unpublish action is always going to be a potential problem. 

For #2, template permissions disappearing, this opens more questions: 

• On how many templates are you defining access?
• Are there any other "superusers" in the system, besides yourself?
• How many roles are you working with? (just one editor role?)
• Do any of these roles have permissions to modify admin pages? 
• You mentioned a "flooded with phone calls" – how many users are we talking about that have access to the admin, and are all trusted users?
• Are all of your users using secure passwords?

[ceberlin]

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.

[ryan]

Unless you've found more info about it, then I'm not sure we can definitely say it was SchedulePages. But it does seem like the most likely at this stage. Also glad to hear there is an explanation for the loss of template role settings. Though I'm still not sure how switching between master and dev could do that (there have been no core changes in this area), but if you switched back to a much older version than 2.3, then it's possible. Glad it sounds like things are coming together and working well!

[ceberlin]

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

[Pete]

I can actually confirm it's SchedulePages that's causing at least the unpublish issue - I meant to post about that a few weeks back as one site's news that used that module had all the news unpublish itself at random - every time I'd re-publish it it would un-publish within 24 hours.

I ended up uninstalling the module and everything was back to normal.

[ceberlin]

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

[ceberlin]

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

[formmailer]

Hi all!

I can actually confirm it's SchedulePages that's causing at least the unpublish issue - I meant to post about that a few weeks back as one site's news that used that module had all the news unpublish itself at random - every time I'd re-publish it it would un-publish within 24 hours.

I ended up uninstalling the module and everything was back to normal.

I am going to look into this and see if I can fix it.

I'll also take a look at the issue Ryan noticed earlier. I actually think that this can be the cause of the problem since the line he mentioned is in the section that checks if a page need to be published or unpublished. But if this is the root cause, I don't get why it worked without problems with version 2.2.

Anyway, I'll get back to you as soon as I know more.

/Jasper

[formmailer]

For #1 I would look at what modules can publish/unpublish, because ProcessWire has no mass-unpublishing capabilities in the core. In looking at your modules list, it looks to me like: SchedulePages, Page Publish/Unpublish and Batcher (if you had it installed). Of those, only SchedulePages and Batcher can do mass unpublishing, and it doesn't look like Batcher is installed.

So I took a closer look at SchedulePages: the module looks to be nicely coded, but I spotted a problem on this line. 

// Select published sites with a publish_until date add them to an array.
$published = wire("pages")->find("status=published, publish_until>0");

It's referring to "status=published" and "published" is not a status keyword recognized by ProcessWire. I think that the author really meant to do: "status<" . Page::statusUnpublished, because there is no published flag in PW, only an unpublished flag (since it's technically a bitmask). Why don't you try to run this selector "status=published, publish_until>0" in your Setup > Selector test, and see what it finds. Reading the rest of the function in SchedulePages, it still seems unlikely that this would be responsible for your unpublishing unless your server's system time inadvertently got reset to something earlier than it was supposed to be? For instance, what if your web host installed an update and had the server's time messed up for a few minutes? That could feasibly produce a mass unpublish event since this module performs unpublish actions connected with time. 

Hi Ryan,

I looked into this "status= thing" and found the following on: http://processwire.com/api/selectors/

The examples above are all focused on including pages in results that wouldn't usually be included, among other pages. But lets say that you want to find only pages that have a hidden, unpublished or locked status. This is a fairly uncommon need, so no need to commit this to memory, but we'll include it for completeness. You can do it by querying the "status" property:

• status=hidden indicates that you only want pages with hidden status to be included in the results.
• status=unpublished indicates that you only want pages with unpublished status to be included in the results.
• status=locked indicates that you only want pages with locked status to be included in the results. 

Is this something that has been changed in the dev branch?

/Jasper

[kongondo]

Hi Ryan,

I looked into this "status= thing" and found the following on: http://processwire.com/api/selectors/

Is this something that has been changed in the dev branch?

/Jasper

Jasper

I think what's being said is that the code has:

status=published which is not valid. What is valid is status=unpublished. So, I suppose, if you want to check if published, you negate the status, i.e. status!=unpublished. I'm probably misunderstanding what you are getting at

[formmailer]

Jasper

I think what's being said is that the code has:

status=published which is not valid. What is valid is status=unpublished. So, I suppose, if you want to check if published, you negate the status, i.e. status!=unpublished. I'm probably misunderstanding what you are getting at

I noticed that, but I am pretty sure status=published used to work in 2.2.

A question to Pete and Ceberlin: did the pages that got unpublished have a short publishing time left (less than 24 hours) before they got unpublished or was it more than a few days off? An important thing for this module is the time zone setting in the config.php file. If this time zone is wrong, pages can be published/unpublished with a few hours difference, depending on the time zone you are in. 

Except for the bove I haven't been able to reproduce this issue yet, I installed a clean PW site and added the module.and everything seems fine.

But I'll wait somewhat longer and will see if something happens.

/Jasper

[ryan]

There hasn't ever been a "status=published" option in ProcessWire that I'm aware of. The status=published would simply translate to a "status=1", which basically means "any page." In this case, the "status=published" seems unlikely to be the source of the problem by itself… even if it isn't a valid option, it doesn't seem to affect the result in a way that would matter. Given that the code still qualifies the publish_until date later, I wasn't able to logically figure out how it could unpublish a bunch of pages, nor could I duplicate the issue myself. The only thing that seemed like a possibility was if the server's date got majorly screwed up, there could be a potential problem. Many servers do nightly maintenance services, and I'm wondering if one of them breaks the clock for a few seconds or something. That was the only thing I could think of?

[formmailer]

Hi Ryan,

If you say that there hasn't ever been a "status=published", it hasn't. I'll take a look at that part of the code and fix it.

A screwed up server time could definitively cause the issue. Together with the TZ thing that's the only explanation that I can think of right now. But like I said, I'll keep the site running at my server and will see what happens.

/Jasper

[ceberlin]

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

[pwired]

Hi,
Is Multi-language page names / URLs now stable in the latest dev branche ?

When I download the dev from here
https://codeload.github.com/ryancramerdesign/ProcessWire/zip/dev

And open the zipfile I see nowhere a latest dev version but# ProcessWire 2.3

By the way the zip file name is ProcessWire-dev.zip and the windows file size = 5,830 Kb

Is this the latest dev ?

Where can I see what dev version I have down loaded ?