Error message after upgrade to 2.7.0 - My Forums

Error message after upgrade to 2.7.0

terrybarth — Nov 29, 2018, 09:20 PM

I started with fresh installation of 2.6.5. I installed a bunch of extras, including the Upgrade Modx widget. I ran the Upgrade Widget to install 2.7.0. The upgrade ran with no errors. However, once I start navigating around my error log starts filling up with this message. It seems clicking any modx menu items or resource will generate another error (all the same).

[2018-11-29 21:09:41] (ERROR in modProcessor::run @ /var/www/html/modx/core/model/modx/modprocessor.class.php : 177) Flat file processor support is deprecated since version 2.7.0.

The sever is running

PHP Version 7.1.8
mysql database version: 5.1.73-log

Thoughts?

Re: Error message after upgrade to 2.7.0

BobRay — Mar 12, 2019, 07:17 PM

This actually triggered my alert for this post; I know a turn key gallery and e-commerce solution or two wink

Sorry, I should have mentioned those. I was thinking of non-commercial extras, but many of the best WordPress solutions are also commercial.

Re: Error message after upgrade to 2.7.0

dejaya — Mar 12, 2019, 10:12 AM

Thanks so much for your replies, Bob & Mark.

I'm certainly reassured to an extent.

Bob, I'd actually read "Most of the MODX core developers have moved to Slack" to mean that they'd moved to develop at Slack instead of MODX.

I'm glad that's not the case!

I will check out MODX on Slack.

I've also promised myself that I'll keep an eye on this forum and try to help where possible.

I'm grateful for your other thoughts on progress.

Mark - I actually discovered some of your sites last night while noseying, including modmore.

You have some really useful and pro-looking extras and I imagine I'll be trying these soon. Sitedash is a revelation

Many thanks to you both again.

Apologies for hijacking this thread.

Re: Error message after upgrade to 2.7.0

markh — Mar 12, 2019, 04:26 AM

The biggest difference between the forum and Slack is that Slack is more realtime/conversational. Slack is definitely flawed in that it's not transparent to anyone not in so it's hard to get a sense for the activity if you're not there.

There is still core and third party code that uses deprecated methods; that's not an immediate problem, but it is useful to know. The core itself still uses the modRestClient for example, so that means the core has to be updated before it can be removed in a future version.

Quote from: BobRay at Mar 11, 2019, 09:35 PM

That said, it's taking a very long time to show up. I found this on the modx.com blog: "In 2013 we will release MODX 3.0." I also found a discussion in 2017 about how long it was taking. I don't know how close it is to being released, but I know there's a lot of MODX3 activity on Slack and GitHub.

I'm disappointed that, as far as I can tell, certain issues will still be there in MODX3. Here are a few of them (take these with a grain of salt -- I could be wrong about any of them and not everyone would agree that they're issues):

One day I hope to figure we'll figure out the right balance between pushing for a release, and pushing forward with making big changes.

There could have been "a version" of MODX3 back in 2013 but it wouldn't have some of the things I'm personally looking forward to most. At the same time, we could also try to address some more things (I would definitely love to unify the modUser and modUserProfile) - but then you're another 3 months down the road. I don't know what the best point is to call it, but I do know it will never be both quick and big enough

It's also a concern that some critical and expected extras like the ones available for WordPress have not shown up (e.g., complete and widely used turnkey solutions for blogging, calendars, photo galleries, e-commerce, threaded forums, etc.).

This actually triggered my alert for this post; I know a turn key gallery and e-commerce solution or two

Re: Error message after upgrade to 2.7.0

BobRay — Mar 11, 2019, 09:35 PM

I don't know the answers to all those questions, and they really belong in their own thread, but I will say a few things anyway.

Slack
Slack is a messaging system, primarily for teams working on a project.

The good: it's tied to GitHub so it's an excellent way for the MODX team to communicate with each other in (more-or-less) real time. It's also a place for MODX users looking for solutions to specific problems to get very fast replies from the core developers.

The bad: Like you, many MODX users are not aware of it. Worse yet, unlike this Forum, it sucks as knowledge base. That means the gurus on there have to answer the same questions over and over, which takes them away from their work on MODX.

MODX3

I think MODX3 will be a big step forward in design and robustness. It will be more accessible, perform better on mobile platforms, and have a number of new features such as composer-based extra installation and Fred.

That said, it's taking a very long time to show up. I found this on the modx.com blog: "In 2013 we will release MODX 3.0." I also found a discussion in 2017 about how long it was taking. I don't know how close it is to being released, but I know there's a lot of MODX3 activity on Slack and GitHub.

I'm disappointed that, as far as I can tell, certain issues will still be there in MODX3. Here are a few of them (take these with a grain of salt -- I could be wrong about any of them and not everyone would agree that they're issues):

Dependence on ExtJS and particularly ExtJS3 (The current version is 6 (2015) -- version 3 was released in 2009)
User data still in two separate tables
Fixed User fields
Fixed Resource fields
TV data stored in multiple tables
All-or-none user management permissions

Health of MODX

I don't really know. A graph of the figures on new MODX adoptions (or at least downloads) would tell us a lot, but I've never seen one.

The activity in this Forum has dropped off significantly in the last year or two, as has the number of informed contributors (some of whom may have moved on to other platforms). This may show declining interest in MODX or just the exodus to Slack, though I'm concerned that new users of MODX won't know about Slack, and even if they do, they will find it daunting and won't use it.

It's also a concern that some critical and expected extras like the ones available for WordPress have not shown up (e.g., complete and widely used turnkey solutions for blogging, calendars, photo galleries, e-commerce, threaded forums, etc.).

I'm taking a wait-and-see attitude.

All that said, I still prefer MODX to any of the alternatives and will continue to develop for it.

Re: Error message after upgrade to 2.7.0

dejaya — Mar 11, 2019, 05:53 PM

Thanks for the reply Bob. Much appreciated.

I'm not up to speed with the politics behind MODX but I feel I should be.

I'm also aware that this is not the place to discuss it in detail but would value your opinion.

I'm quite heavily invested in MODX with dozens of live sites.

MODX 3 in development - good news?

"Most of the MODX core developers have moved to Slack" - bad news? [also what is Slack?]

How healthy is MODX just now?

Thanks again.

Re: Error message after upgrade to 2.7.0

BobRay — Mar 10, 2019, 10:03 PM

I think the hope is that extra developers will clean things up to eliminate the error before MODX 3 comes out. Possibly the "deprecated" code will throw actual errors in MODX 3.

Most of the MODX core developers have moved to Slack and seldom, if ever, visit the Forums. That may be why there's no 2.7 sub-forum.

Re: Error message after upgrade to 2.7.0

dejaya — Mar 07, 2019, 09:25 AM

Quote from: BobRay at Jan 22, 2019, 02:53 AM

My advice is to turn off the log_deprecated System Setting until MODX 2.7.1 is released.

Looks like 2.7.1 did not address this issue?

I still receive this error on installation of most extras. Anyone else? The extras seem to work OK.

I can live with it - or follow BobRay's advice to turn off the log_deprecated System Setting - but this is the sort of thing that will make new users turn away. Makes MODX look flakey.

Also - why is there no Revo 2.7 subforum here?

Re: Error message after upgrade to 2.7.0

lizardx — Feb 01, 2019, 09:29 PM

https://github.com/modxcms/Quip/issues/25 is more or less the Quip issue.

The following assumes elementary competence, that is, you can SSH into the server, and run the commands, and you know where your directories are located in that file system.

There's no real need to overthink the cause, since the file that is creating the issue must contain the class name string in the deprecation warning.

Given warnings:

[2019-02-01 11:13:48] (ERROR in xPDO::getService @ /modx-core/xpdo/xpdo.class.php : 1234) modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.
[2019-02-01 11:13:48] (ERROR in modRestCurlClient::__construct @ /modx-core/model/modx/rest/modrestcurlclient.class.php : 26) modRestClient::__construct is deprecated since version 2.3.0. Use the modRest classes instead.

you can find the sources with a simple command line search for the class name, in this case, modRestClient (assume main folder modx is in one location, and your site is in 'site' folder).

grep -snR 'modRestClient' modx/ site/ | grep -v error.log

if your modx folder is in your main site folder, you'd just do:

grep -snR 'modRestClient' site/ | grep -v error.log

one level below document root. Or ./ if in document root.

If you are getting this error, that's where you find the source, just get the main classname, and plug it into the search. Windows syntax would be different, can't help there.

In our case only Quip has the deprecation trigger of all the extensions. We are getting the flatfile thing, but that is apparently going away in 2.7.1.

The above returns the following, but you can ignore the actual class files since we're only interested in what is creating that class, in this case stopforumspam.class.php:

components/quip/model/stopforumspam/stopforumspam.class.php:71:     * @return modRestClient/boolean
components/quip/model/stopforumspam/stopforumspam.class.php:75:            $this->modx->getService('rest','rest.modRestClient');
docs/changelog.txt:2019:- Fixed missing options array call in modRestClient, isArray call in modRestCurlClient
docs/changelog.txt:2200:- Cleaned up and better abstracted modRestClient and modRestCurlClient code
model/modx/rest/modrestsockclient.class.php:19:class modRestSockClient extends modRestClient {
model/modx/rest/modrestsockclient.class.php:21:     * Extends modRestClient::request to provide socket-specific request
model/modx/rest/modrestsockclient.class.php:38:        $purl['path'] = !empty($purl['path']) ? $purl['path'] : $this->config[modRestClient::OPT_PATH];
model/modx/rest/modrestsockclient.class.php:39:        $purl['port'] = !empty($purl['port']) ? $purl['port'] : $this->config[modRestClient::OPT_PORT];
model/modx/rest/modrestsockclient.class.php:53:                ."User-Agent: ".$this->config[modRestClient::OPT_USERAGENT]."\r\n"
model/modx/rest/modrestcurlclient.class.php:20:class modRestCurlClient extends modRestClient {
model/modx/rest/modrestcurlclient.class.php:31:     * Extends modRestClient::request to provide cURL specific request handling
model/modx/rest/modrestcurlclient.class.php:70:     * @see modRestClient::request for parameter documentation.
model/modx/rest/modrestcurlclient.class.php:124:        curl_setopt($ch, CURLOPT_TIMEOUT, !empty($options['curlopt_timeout']) ? $options['curlopt_timeout'] : $this->config[modRestClient::OPT_TIMEOUT]);
model/modx/rest/modrestcurlclient.class.php:128:        curl_setopt($ch, CURLOPT_USERAGENT, !empty($options['curlopt_useragent']) ? $options['curlopt_useragent'] : $this->config[modRestClient::OPT_USERAGENT]);
model/modx/rest/modrestcurlclient.class.php:159:        if (!empty($options[modRestClient::OPT_USERPWD])) {
model/modx/rest/modrestcurlclient.class.php:160:            $options[modRestClient::OPT_AUTHTYPE] = $this->modx->getOption(modRestClient::OPT_AUTHTYPE,$options,'BASIC');
model/modx/rest/modrestcurlclient.class.php:161:            switch ($options[modRestClient::OPT_AUTHTYPE]) {
model/modx/rest/modrestcurlclient.class.php:169:            $auth = curl_setopt($ch, CURLOPT_USERPWD, !empty($options[modRestClient::OPT_USERPWD]) ? $options[modRestClient::OPT_USERPWD] : 'username:password');
model/modx/rest/modrestclient.class.php:19:class modRestClient {
model/modx/rest/modrestclient.class.php:60:     * @var modRestClient $conn The client connection instance to use.
model/modx/rest/modrestclient.class.php:82:     * The constructor for the modRestClient class. Assigns a modX instance
model/modx/rest/modrestclient.class.php:87:     * @return modRestClient
model/modx/rest/modrestclient.class.php:92:            modRestClient::OPT_PORT => 80,
model/modx/rest/modrestclient.class.php:93:            modRestClient::OPT_TIMEOUT => 30,
model/modx/rest/modrestclient.class.php:94:            modRestClient::OPT_PATH => '/',
model/modx/rest/modrestclient.class.php:95:            modRestClient::OPT_USERAGENT => "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)"
model/modx/rest/modrestclient.class.php:141:        $responseClass = $this->modx->getOption(modRestClient::OPT_RESPONSE_CLASS,$this->config,'modRestResponse');
model/modx/rest/modrestclient.class.php:214:     * @param modRestClient &$client A reference to the modRestClient instance.
model/modx/rest/modrestclient.class.php:219:    function __construct(modRestClient &$client, $response, $responseType = 'xml') {
model/modx/transport/modtransportprovider.class.php:14: * @uses modRestClient This REST implementation is used to communicate with a
model/modx/transport/modtransportprovider.class.php:327:        /** @var modRestClient $rest */
model/modx/transport/modtransportprovider.class.php:328:        $rest = $this->xpdo->getService('rest','rest.modRestClient');
model/modx/transport/modtransportprovider.class.php:413:     * @return modRestClient|bool A REST client instance, or FALSE.
model/modx/transport/modtransportprovider.class.php:417:            $this->xpdo->getService('rest','rest.modRestClient');
model/modx/modx.class.php:214:     * @var modRestClient $rest

Re: Error message after upgrade to 2.7.0

BobRay — Jan 22, 2019, 02:53 AM

Thanks for the kind words. I'm fairly certain that CreateXpdoClasses isn't causing those errors because it doesn't call any processors.

The way 2.7.0 works, the errors can be thrown for extras that are not even executing. My advice is to turn off the log_deprecated System Setting until MODX 2.7.1 is released. That should quiet most of the errors.

I have a blog article in the works about how to tell what is triggering the errors but it won't be out for some time.