Uncaught Error: Class 'VWP\Enqueues'

[tiptronic]

Hi Mat, I'm not sure, if I like the idea of bundling everything into a single plugin:

1. If I already have vue linked, there are suddenly 2 vue frameworks bundled (adding ~90kb)
2. The plugin gets huge and - if I manage my WP-install in GIT (or even go a step further and use bedrock), I have tons of needless data in my repo, making it hard to track changes.
3. Finally the plugin as is did not work for me. I added the plugin to a blank WP-install (just using html5blank) and get this: Fatal error: Uncaught Error: Class 'VWP\Enqueues' not found in /volume1/web/blank/wp-content/plugins/vue-wordpress-plugin/vwp.php:26 Stack trace: #0 /volume1/web/blank/wp-admin/includes/plugin.php(1897): include() #1 /volume1/web/blank/wp-admin/plugins.php(172): plugin_sandbox_scrape('vue-wordpress-p...') #2 {main} thrown in /volume1/web/blank/wp-content/plugins/vue-wordpress-plugin/vwp.php on line 26

I think I'm still 'all in' for traditional plugin development. While webpack, ES6, etc... certainly make some sense for bigger applications, for components/plugins it's just overkill. If I were to create something, I'd most likely create a theme...

Anyway - interesting approach. Andy

[juwul]

Same issue here.

[matgargano]

Hey @tiptronic and @juwul -- thanks for the feedback - this is a busy time of year so sorry it took so long to get back to you guys.

As far as your (1) above, I responded in another comment:

The problem is -- there is no central VueJS within WordPress - if
it enqueues with a handle of `vue-js` and someone else enqueues it as
`vuejs` we will end up with a duplicate anyway and an extra roundtrip to the server which would negatively impact users if you are using HTTP 1.1.

As far as (2) above -- what files make it huge?

As far as (3) -- are you running composer install? This project uses composer's autoloader -- which should autoload the classes that it says are not found. Maybe we could do a screenshare?

[juwul]

Hey @matgargano Thanks for a nice repo. The idea of a Vue app inside a plugin is brilliant! :)

I followed this fix; https://github.com/matgargano/vue-wordpress-plugin/issues/3#issue-279369904 and was able to activate, but I have not tested it on that setup yet.

[matgargano]

Thanks @juwul --- that's a hack -- the files should be autoloading with composer (https://github.com/matgargano/vue-wordpress-plugin/blob/master/vwp.php#L24)... are you running composer install? try running composer dump-autoload -o from the plugin root

When I have a few minutes today I'll install this on a vanilla WP install and see if I can replicate.

[juwul]

@matgargano Yes, I ran the composer install. I have only experienced the error when doing it on my server (not on my local setup) and after I wrote here the other day I had some unexcepted errors on my server that resulted in Layerslide (a plugin) did not work. So I digged into these errors and it was related to missing php extensions. These were missing;

php7 MbString extension php7 ZipArchive Extension php7 DOMDocument extension

Which can be installed with the follwing commands; sudo apt-get install php7.0-mbstring sudo apt-get install php7.0-zip sudo apt-get install php-xml

Remember to restart apache; sudo service apache2 restart

Maybe it is related? I do not have access to the same server as I did two days ago so I can not test it right now.

[matgargano]

Hey @juwul and @tiptronic --

I just set up a vanilla WP, added my plugin by checking it out - then ran -- in the plugin directory--

composer install
npm install
npm run build

Activated the plugin (as is) added

<div id="app"></div>

and it worked as expected -- I can have a screenshare if you'd like

[juwul]

@matgargano Great! When/if I can test on that same server as I used two days ago I will be able to confirm if the problem is gone after installing php extensions.

[matgargano]

@juwul any updateS?

[juwul]

@matgargano no I haven't worked with WP since last time I wrote here. We are getting some WP project as we speak so maybe I will get it a run in near future. I have flagged this as to-do :) Sorry I'm not to any help atm.

[matgargano]

I'm going to close this, please reopen if you need to

[balde73]

Hi @matgargano, I ran into the same problem as OP. Of course I was able to solve this using composer dump-autoload -o as you suggested. However, since I experienced this problem only on my server (not on my local setup) as @juwul, I decided to invest some time searching for what could cause this. What solved the problem for me (without using composer dump-autoload -o every time) was renaming the php file from enqueues.php to Enqueues.php using the capital letter as PSR-4 documentation. I would cite some text from this answer from axiac

PSR-4 (and also PSR-0) requires that the class ClassName is stored in a file named ClassName.php. The names are case sensitive and they must match exactly. The file names in your project are lowercase, the class names are mixed case. The default disk formats on Windows and macOS are case-insensitive on search. This means when a program searches for Employee.php and the file employee.php exists in the directory, the search succeeds and the OS returns the existing file even if the case of its name is not the same as the case of the required file. On Linux-based OSes, the default disk format is case sensitive and a program that searches for Employee.php cannot find employee.php. [ ... ] Each class must be stored in the correct subdirectory, in a file that has the same name as the class (including the case) and the termination .php (lowercase). For example, the class MyDomain\Models\Employee must stay in the file app/Models/Employee.php.

So I suggest you to rename the file name. I hope this could help others. Nice job and thanks a lot for your project! Federico

[matgargano]

Awesome - can you send a PR?

On Wed, Aug 1, 2018 at 5:00 AM Federico Baldessari notifications@github.com wrote:

Hi @matgargano https://github.com/matgargano, I ran into the same problem as OP. Of course I was able to solve this using composer dump-autoload -o as you suggested. However, since I experienced this problem only on my server (not on my local setup) as @juwul https://github.com/juwul, I decided to invest some time searching for what could cause this. What solved the problem for me (without using composer dump-autoload -o every time) was renaming the php file from enqueues.php to Enqueues.php using the capital letter as PSR-4 documentation. I would cite some text from this answer https://stackoverflow.com/questions/41784405/need-to-dump-autoload-to-everytime-i-add-a-new-class from axiac

PSR-4 (and also PSR-0) requires that the class ClassName is stored in a file named ClassName.php. The names are case sensitive and they must match exactly. The file names in your project are lowercase, the class names are mixed case. The default disk formats on Windows and macOS are case-insensitive on search. This means when a program searches for Employee.php and the file employee.php exists in the directory, the search succeeds and the OS returns the existing file even if the case of its name is not the same as the case of the required file. On Linux-based OSes, the default disk format is case sensitive and a program that searches for Employee.php cannot find employee.php. [ ... ] Each class must be stored in the correct subdirectory, in a file that has the same name as the class (including the case) and the termination .php (lowercase). For example, the class MyDomain\Models\Employee must stay in the file app/Models/Employee.php.

So I suggest you to rename the file name. I hope this could help others. Nice job and thanks a lot for your project! Federico

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/matgargano/vue-wordpress-plugin/issues/5#issuecomment-409504143, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMCssuHDbiSUxKMQbBnUtg8rm2xw2T7ks5uMW4ggaJpZM4REtz3 .